Mac OS X неправильно сообщает размеры каталогов?

Question

В Finder я заметил, что если я дублирую некоторые файлы .app (в папке «Программы»), Finder покажет, что дубликат файла .app не соответствует размеру оригинала. Это несоответствие размера файла не происходит для всех файлов .app, которые я дублирую, но кажется, что чем больше файл .app, тем больше вероятность того, что дубликат не будет иметь тот же размер, что и оригинал. Вот некоторые примеры:

GarageBand.app - 381.7 MB
GarageBand copy.app - 373.2 MB

iMovie.app - 695.3 MB
iMovie copy.app - 635.4 MB

Install Xcode.app - 1.81 GB
Install Xcode copy.app - 1.57 GB

Теперь я новичок в Mac, и после того, как я заметил эту проблему несоответствия размера файла, я обнаружил, что файлы .app на самом деле не являются файлами - они действительно являются каталогами, но Finder отображает их, как если бы они были файлами. Поэтому я подумал, что, возможно, процесс дублирования не скопировал все содержимое исходного каталога .app, и это объяснило разницу в "размере файла". Но затем я скачал и установил DeltaWalker, который является средством сравнения файлов и папок, и DeltaWalker сказал, что дубликаты каталогов .app были точно такими же, как и исходные каталоги .app. Таким образом, процесс дублирования работал отлично, и, следовательно, это проблема с файлами отчетов Finder.

Я также проверил размеры каталогов в Терминале, используя команду "du", и это также показывает расхождения в размерах между исходными и дублирующими каталогами:

du -k /Applications/GarageBand.app/
212868  /Applications/GarageBand.app/

du -k /Applications/GarageBand\ copy.app/
397880  /Applications/GarageBand copy.app/

du -k /Applications/iMovie.app/
629644  /Applications/iMovie.app/

du -k /Applications/iMovie\ copy.app/
700500  /Applications/iMovie copy.app/

du -k /Applications/Install\ Xcode.app/
1771864 /Applications/Install Xcode.app/

du -k /Applications/Install\ Xcode\ copy.app/
1772228 /Applications/Install Xcode copy.app/

Кроме того, это не просто каталоги .app. Я продублировал свой каталог /Developer /Library, и вот что сказал du:

du -k /Developer/Library/
320784  /Developer/Library/

du -k /Developer/Library\ copy/
399868  /Developer/Library copy/

Так кто-нибудь может объяснить, почему Mac OS X, кажется, не сообщает правильно размеры каталогов? Это ошибка (в которую трудно поверить, что-то такое простое), или я что-то упускаю (будучи новым пользователем Mac)?

(Я использую Mac OS X Lion 10.7.2)

---

ОБНОВЛЕНИЕ в ответ на elofturtle:

Что самое странное в этом, это то, что Finder не имеет последовательности. Я только что сделал 2 дубликата GarageBand.app, а затем сделал 2 дубликата одного из дубликатов. Finder отображает каждый дубликат с другим размером:

GarageBand.app - 381.7 MB
GarageBand copy.app - 357.6 MB (duplicate of GarageBand.app)
GarageBand copy 2.app - 353.9 MB (duplicate of GarageBand.app)
GarageBand copy 3.app - 378.2 MB (duplicate of GarageBand copy 2.app)
GarageBand copy 4.app - 329.1 MB (duplicate of GarageBand copy 2.app)

Также обратите внимание, что «GarageBand copy 3.app» больше, чем «GarageBand copy 2.app», а «GarageBand copy 4.app» меньше, чем «GarageBand copy 2.app». Это должно быть ошибка в Finder.

Вот что «ду-к» говорит обо всех них:

212868  /Applications/GarageBand.app/
397880  /Applications/GarageBand copy.app/
397880  /Applications/GarageBand copy 2.app/
397880  /Applications/GarageBand copy 3.app/
397880  /Applications/GarageBand copy 4.app/

По крайней мере, в нем говорится, что все дубликаты имеют одинаковый размер, но они не того же размера, что и оригинал.

Answer 1

Различия произошли по разным причинам: разные способы подсчета, разные инструменты, сжатие и что-то похожее на ошибку.

Первая разница в размере, которую вы видите, - это ошибка в Finder. Размеры файлов, показанные Finder, каким-то образом рассчитываются в реальном времени и кэшируются .DS_Store файлы. По какой-то причине, при дублировании большого приложения / папки, Finder вычисляет его размер в процессе копирования и кэширует, а затем и неполный размер. Затем этот размер отображается серым цветом в окнах Finder, а серый означает, что Finder знает, что содержимое изменилось с момента последнего расчета размера, но еще не пересчитал его.

Единственный способ, как я нашел, чтобы правильно пересчитать размер, это удаление .DS_Store в папке «Приложение», затем выйдите из Finder (например, из монитора активности) и снова запустите его (из значка Dock). Если вы не удалите .DS_Store остается серым. Возможно, некоторое время ожидания (часы, дни, перезагрузка, ...) заставит Finder сделать это самостоятельно.

После этого вы должны увидеть, что все размеры, указанные Finder, одинаковы.

Так что да, это похоже на ошибку Finder, по крайней мере, в OSX Lion (здесь протестировано с 10.7.4, версия Finder 10.7.3). Вы также можете увидеть эту ветку, которая сообщает о таком же поведении.

Тогда давайте рассмотрим инструмент du . Сначала я подумал, что разницу, которую мы видим, можно объяснить разницей между логическим и физическим размерами копируемых элементов. Логический размер - это реальный размер элемента, то есть каждый бит информации, который он содержит, складывается вместе. Физический размер - это размер элемента на диске, где каждый информационный бит записывается в сектор диска.

Например, файл, содержащий один символ, будет иметь логический размер 1 байт, но физический размер 512 байт или даже 4096 байт при реальной записи на диск. Физический размер обычно больше, чем логический размер (и зависит от фактического размера сектора / блока диска или файловой системы). Это объясняется более подробно в этой другой теме. Логический размер может быть больше в случае разреженных файлов, но HFS+, похоже, не поддерживает такую функцию.

du показывает только физический размер (и вы можете сказать, что такое BLOCKSIZE). Вы можете видеть, что размер, сообщаемый du , всегда больше (или, в исключительных случаях, тот же), что и оригинал. Это из-за фрагментации файловой системы и дискового пространства. Когда вы копируете файл (на самом деле здесь набор файлов, поскольку приложение является каталогом), на диске выделяются новые сектора, и, когда происходит фрагментация , количество используемых блоков обычно больше, чем у исходного элемента. Некоторые люди называют это File Slack.

Теперь вернемся к Finder. Если вы откроете окно получения информации о приложениях, которые вы продублировали, вы увидите, что Finder фактически сообщает как о логическом, так и о физическом размере выбранного вами элемента. Что тогда имеет смысл. Вы даже сможете сравнить физический размер, указанный в Finder, и размер, указанный в du если вы немного разберетесь в математике.

Зачем делать математику? Потому что Finder показывает размеры файлов в килобайтах, МБ или ГБ, где du сообщает о них в килобайтах, миБ или гиБ. Это двоичные префиксы МЭК, которые должны использоваться для вычисления и отображения единиц цифровой информации.

Но, на самом деле, я не уверен, что File Slack замешан здесь, есть кое-что еще. Тома HFS+ позволяют выполнять сжатие прозрачным образом, и Apple использует его для исходных элементов, установленных ОС. Затем, когда файлы копируются с использованием стандартных инструментов, сжатие больше не используется (по умолчанию для обратной совместимости). Если вы хотите сохранить сжатие этих файлов, вам нужно использовать команду ditto вместо cp или любое действие Finder. Это объясняется в этом обзоре.

Вот результат копирования iTunes.app с использованием различных методов. Вы увидите, что то же самое делает приложение точно такого же размера, сохраняя сжатие, а cp - нет. И вы даже можете удалить двоичный файл для ненужной вам арки, а затем уменьшить весь размер):

antoine@amarante:/Applications$ du -ms iTunes.app/
281 iTunes.app/
antoine@amarante:/Applications$ cp -a iTunes.app/ iTunes-copy.app/
antoine@amarante:/Applications$ ditto iTunes.app/ iTunes-ditto.app
antoine@amarante:/Applications$ ditto --arch x86_64 iTunes.app/ iTunes-64.app
antoine@amarante:/Applications$ du -ms iTunes*
236 iTunes-64.app
289 iTunes-copy.app
281 iTunes-ditto.app
281 iTunes.app

Спасибо @DanPritts за ответ на мой дополнительный пост.

Answer 2

Это ужасный недостаток / ошибка в OS X. Самый простой способ увидеть это - скопировать большой пакет приложений, затем показать содержимое и удалить огромный файл изнутри. Пространство не восстановится. Файл все еще огромен. Например, если у вас есть пакет приложений 3,5 ГБ, вы показываете содержимое, а затем удаляете 3 ГБ из него, теперь у вас должно быть приложение с размером файла 500 МБ. Ты не будешь. Это все еще будет 3,5 ГБ.

Answer 3

Это в основном предположение, но я вижу две возможности:

1. Некоторые данные были удалены, но не были освобождены в оригинале, и они не копируются. Тем не менее, он обнаруживается в некоторых поисках использования диска, но не в других (различные параметры, заданные для du или любой другой OS X, используется внутри).
2. Некоторые данные связываются с исходным местоположением, и это влияет на воспринимаемый размер в разных инструментах.

Если (1) вы, вероятно, должны получить другие результаты, делая третью копию и сравнивая копии.

Answer 4

Во-первых, вы должны знать, что файлы .app для Mac на самом деле являются каталогами, а не скомпилированными двоичными файлами, такими как файлы .exe Windows. Finder просто скрывает этот факт от вас для папок с именем * .app.

например (из терминала)

# cd /Applications/Calculator.app
# ls
Contents/

Я почти уверен, что происходит то, что Finder / Get Info использует не очень умную эвристику для вычисления размера папки .app. Это означает, что не нужно перечислять каждую подпапку и файл и складывать все эти размеры.

Я предполагаю, что оценка на копии верна, потому что OSX недавно должен был проверять каждый файл в нем, когда вы делали копию, тогда как на оригинале OSX, возможно, никогда не делали этого (например, при заводской установке)

Answer 5

У меня была эта проблема с моим домашним каталогом, когда я переместил его на внутренний жесткий диск после установки Yosemite на SSD. При использовании «Get Info» сообщалось о неправильном размере всего 8 ГБ, хотя в строке состояния Finder отображался правильный размер 240 ГБ. Я исправил это, щелкнув Get Info в папке Users, который затем рассчитал правильно и исправил неверный размер, о котором сообщает Home Directory.