Вопросы Теги

Почему du сообщает о размере 0 для некоторых непустых файлов на HFS + раздел?

Если требуется сравнить только структуру и некоторую основную информацию о файлах, можно попробовать что-то вроде этого:

diff <(cd $DIR1 && ls -laR) <(cd $DIR2 && ls -laR)

Я не протестировал его, таким образом, любые редактирования приветствуются :)

5
18.10.2013, 20:07
3 ответа

Я, возможно, нашел что-то:

Команда ls на OS X имеет этот переключатель:

  -O      Include the file flags in a long (-l) output.

Результат:

$ ls -O Info.plist
-rw-r--r--  1 root  wheel  compressed 15730 11 jui 15:02 Info.plist

Я просто проверил (экспериментально) это du всегда отчеты 0 для HFS + сжатые файлы.

Сжатые файлы копирования распаковывают их; так логически du сообщает корректный файл относительно скопированного, несжатого файла.

Вот объяснение поведения du:

HFS + сжатие файла

В Mac OS X 10.6, Apple представила сжатие файла в HFS +. Сжатие чаще всего используется для файлов, установленных как часть Mac OS X; пользовательские файлы обычно не сжимаются (но конечно может быть!). Чтение и запись сжатых файлов прозрачны до API файловой системы Apple.

Сжатые файлы имеют пустую ветвь данных. Это означает, что судебные инструменты, не знающие о HFS + сжатие файла (включая TSK прежде 4.0.0), не будут видеть данных, связанных со сжатым файлом!

Существует также обсуждение этого предмета в Mac OS X and iOS Internals: To the Apple's Core Jonathan Levin, в главе 16: К B (-Дерево) или не быть - HFS + файловые системы.

Также afsctool может помочь видеть, какие файлы сжаты в папке.

$ afsctool -v /Applications/Safari.app/
/Applications/Safari.app/.:
Number of HFS+ compressed files: 1538
Total number of files: 2247
Total number of folders: 144
Total number of items (number of files + number of folders): 2391
Folder size (uncompressed; reported size by Mac OS 10.6+ Finder): 29950329 bytes / 34.7 MB (megabytes) / 33.1 MiB (mebibytes)
Folder size (compressed - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 21287197 bytes / 23.8 MB (megabytes) / 22.7 MiB (mebibytes)
Folder size (compressed): 22694835 bytes / 25.2 MB (megabytes) / 24 MiB (mebibytes)
Compression savings: 24.2%
Approximate total folder size (files + file overhead + folder overhead): 26353338 bytes / 26.4 MB (megabytes) / 25.1 MiB (mebibytes)
6
27.01.2020, 20:37

При использовании du и Вы сравниваете результаты 2 различных выполнений с файловыми системами, необходимо удостовериться, что использовали переключатель --apparent-size.

Пример

Вот смонтированная доля CIFS.

$ du -sh somedir
50M somedir

$ du -sh --apparent-size somedir
45M somedir

выборка из du страницы справочника

--apparent-size
          print  apparent  sizes,  rather than disk usage; although the apparent 
          size is usually smaller, it may be larger due to holes in (‘sparse’)
          files, internal fragmentation, indirect blocks, and the like

Так что происходит?

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

Что относительно 0B размера?

0B/Applications/Safari.app/Contents/Info.plist

Это наиболее вероятно ссылка. Выполнение этой команды покажет, если это верно.

$ ls -l /Applications/Safari.app/Contents | grep Info.plist
2
27.01.2020, 20:37
  • 1
    , от который ОС? –  alecail 17.10.2013, 18:18
  • 2
    @AntoineLecaille из Linux, к сожалению, BSD du (который является тем, что OSX использует), не имеет той опции. –  terdon♦ 17.10.2013, 18:20
  • 3
    @AntoineLecaille - ищут переключатель к Вашему du это указывает что-то относительно "очевидного" или "размера". Можно всегда устанавливать версию GNU du также. –  slm♦ 17.10.2013, 18:24
  • 4
    @terdon - одна причина была бы этим, если бы файлы использовали части нескольких блоков. du сообщил бы фрагментированный каталог как больше, чем копия. При копировании файлов с одного местоположения на диске другому, система имеет возможность сделать "дефрагментацию" и консолидировать данные файлов в меньшее количество блоков. –  slm♦ 17.10.2013, 18:33
  • 5
    @AntoineLecaille - другой вещью, которую я видел с OSX, являются те .plist файлы, просто ссылки. Можно ли подтвердить, является ли это фактическим файлом или ссылкой на некоторый другой файл? Это объяснило бы 0 размеров. –  slm♦ 17.10.2013, 18:37

Мой ответ в строке с другими, но я пока не могу комментировать, поэтому я начинаю с нового:

Большинство файлов в /Applications сжаты, и когда вы их копируете, они теряются. При использовании сжатия в HFS+ данные файлов хранятся в ресурсной вилке OR расширенный атрибут, если он достаточно мал (менее 4k). Если он находится в ресурсной вилке du (по крайней мере, на Yosemite), то он будет показывать фактическое использование диска в блоках. Если он полностью в атрибуте, то покажет 0.

.
0
27.01.2020, 20:37

Теги

Похожие вопросы