Mac OS X не повідомляє розміри каталогів правильно?


17

У Finder я помітив, що якщо я копіюю кілька файлів .app (у папці Applications), 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

Тепер я новачок у Macs, і, помітивши цю проблему з розбіжністю розміру файлів, я виявив, що .app файли насправді не файли - це справді каталоги, але Finder відображає їх так, ніби це файли. Тому я подумав, що, можливо, процес копіювання не скопіював увесь вміст вихідного каталогу .app, і це пояснило різницю у "розмірі файлу". Але потім я завантажив і встановив DeltaWalker, який є інструментом для розходження файлів / папок, і DeltaWalker сказав, що дублікати каталогів .app точно такі ж, як і оригінальні каталоги .app. Таким чином, процес дублювання працював ідеально, і тому здається, що це проблема з розмірами файлів звітів Finder.

Я також перевірив розміри каталогів у Terminal, використовуючи команду "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. Я продублював каталог / розробник / бібліотека, і ось що сказав:

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.

Ось що "du -k" говорить про всіх них:

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/

Принаймні, там сказано, що всі дублікати однакового розміру, але вони не такого розміру, як оригінал.


У мене є переконання, що це зводиться до жорстких посилань та посилань, і одна чи інша частина тих, що перетворюються на окремі копії файлів, коли ви дублюєте ці пакети .app. До речі, ти їх дублюєш в одному і тому ж томі (розділі?).
Шпіф

Чи є щось, що бракує моїй відповіді нижче? У мене таке враження, що це повноцінна відповідь на ваше запитання, але поки що коментарів від вас не було. Чи можете ви, будь ласка, дайте мені знати?
Тонін

1
Прошу вибачення за затримку. Ваша відповідь надійшла після того, як я втратив інтерес до питання. Але ваша відповідь чудова - дуже детальна, і вона справді повністю відповідає моєму питанню. Дуже дякую, і мені доведеться пам’ятати, що Finder відображає нестиснені розміри, навіть якщо файл / папка насправді стиснута.
pacoverflow

Повторно позначивши це, можливо, я мав би його позначити [копіювати]? - Але за рахунок якої іншої бирки?
Arne Stenström

Відповіді:


13

Відмінності виникали з різних причин: різні способи підрахунку, різні інструменти, стиснення та те, що схоже на помилку.

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

Єдиний спосіб, щоб я міг правильно перерахувати розмір, - це видалити .DS_Storeфайл у папці програми, потім вийти з Finder (наприклад, з Монітора активності) та повторно запустити його знову (з піктограми дока). Якщо ви не видалите .DS_Storeфайл, він все ще залишається сірим. Можливо, очікування деякого часу (години, дні, перезавантаження, ...) змусить Finder зробити це сам.

Після цього слід побачити, що всі розміри, про які повідомляє Finder, однакові.

Так, так, це схоже на помилку Finder, принаймні в OSX Lion (протестовано з 10.7.4 тут, Finder версії 10.7.3). Ви також можете побачити цю тему, яка повідомляє про таку саму поведінку.

Потім розглянемо duінструмент. Спочатку я вважав, що різницю, яку ми бачимо, можна пояснити різницею між логічними та фізичними розмірами елементів, що копіюються. Логічний розмір - це реальний розмір предмета, тобто кожен бит інформації, який він містить, додається разом. Фізичний розмір - це розмір елемента на диску, де кожен інформаційний біт записується на диск-секторі.

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

duпоказує лише фізичний розмір (і ви можете сказати, що це за BLOCKSIZE). Ви можете бачити, що розмір, про який повідомляється, duзавжди більший (або, винятком, той самий), що і оригінал. Це відбувається через фрагментацію файлової системи та дискового простору. Коли ви копіюєте файл (фактично тут купу файлів, оскільки додаток - це каталог) на диск виділяються нові сектори, і в міру виникнення фрагментації кількість використаних блоків зазвичай перевищує кількість вихідного елемента. Дехто називає цей файл слабким .

Тепер повернемось до Finder. Якщо ви відкриєте вікно отримання інформації про копіювані програми, ви побачите, що Finder фактично звітує як про логічний, так і про фізичний розмір обраного вами елемента. Що тоді має сенс. Ви навіть зможете порівняти фізичний розмір, про який повідомляє Finder, і той, про який повідомляється, duякщо ви трохи по математиці.

Навіщо займатися математикою? Оскільки Finder показує розміри файлів у kB, MB або GB, де duповідомляє про них у kiB, MiB або GiB. Це бінарні префікси IEC, які слід використовувати для обчислення та відображення одиниць цифрової інформації.

Але насправді я не впевнений, що тут є задіяний файл File Slack. Є ще щось. Обсяги HFS + дозволяють стиснути , виконувати прозоро, і Apple використовує це для оригінальних елементів, встановлених ОС. Потім, коли файли копіюються за допомогою стандартних інструментів, стискання більше не використовується (як типово, щоб бути сумісним назад). Якщо ви хочете зберегти стиснення цих файлів, вам потрібно використовувати dittoкоманду замість cpбудь-якої дії Finder. Це пояснено в цьому огляді .

Ось вихід копіювання iTunes.app з використанням різних методик. Ви побачите, що ditto робить додаток точно такого ж розміру, зберігаючи стиснення, де 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 за його відповідь на моє додаткове повідомлення .


Чи не навпаки? Finder показує фактичні префікси SI.
Даніель Бек

Чи не розрізнені файли ( не розріджені пакети / зображення ОС X) мають більший логічний розмір, ніж фізичний розмір файлу?
Даніель Бек

Так, ви маєте рацію, Finder показує префікси SI та duIEC, я виправлю свій пост.
Тонін

@DanielBeck Рідкі файли, теоретично це може бути, так, але які саме файли матиме додаток OSX як рідкісні файли? Згідно з wikipedia , розріджені файли не підтримуються в HFS +.
Тонін

Цей абзац звучить так, що він загальноприйнятний ( залежить від фактичного розміру сектора / блоку диска або файлової системи ), тому я хотів це зазначити.
Даніель Бек

1

Це жахливий недолік / помилка в OS X. Найпростіший спосіб це побачити - це дублювати великий пакет програм, а потім показати вміст і видалити величезний файл зсередини. Простір не відновиться. Файл все ще величезний. Наприклад, якщо у вас є пакет додатків об'ємом 3,5 ГБ, ви показуєте вміст, а потім виймаєте з нього 3 ГБ, тепер у вас має бути програма з розміром файлу 500 Мб. Ти не. Це все одно буде 3,5 ГБ.


Для перерахунку розмірів виберіть Розрахувати всі розміри в параметрах подання папки. Дивіться apple.stackexchange.com/a/227173/156178
asmaier

0

Це в основному здогадка, але я бачу дві можливості:

  1. Деякі дані були видалені, але не розміщені в оригіналі, і це не скопійовано. Однак він відображається в деяких пошуках використання диска, але не в інших (різні параметри, задані du або будь-якій OS X використовується внутрішньо).
  2. Деякі дані пов'язуються з оригінальним розташуванням, і це впливає на сприйнятий розмір у різних інструментах.

Якщо (1) ви, мабуть, отримаєте різні результати, зробивши третю копію та порівнявши копії.


На жаль, не вдається отримати багаторядкові блоки коду, щоб виглядати прямо в коментарі, тому я спробую редагувати своє початкове повідомлення.
pacoverflow

Я б не очікував, що дублікати будуть більшими, ніж оригінал: - / Здається, доповідь про помилку, але я ризикую отримати шанси отримати будь-який зворотній зв'язок про внутрішню роботу Finder, що спричинить це, невеликі. Сподіваємось, вони все-таки поглянуть на це.
elofturtle

0

По-перше, ви повинні знати, що файли Mac .app насправді - це каталоги , а не компільовані бінарні файли, такі як файли Windows .exe. Finder просто приховує від вас цей факт для папок, що називаються * .app.

наприклад (з терміналу)

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

Я впевнений, що відбувається в тому, що Finder / Get Info використовує деякі не дуже розумні евристики для обчислення розміру папки .app. Це означає, що не потрібно перераховувати кожну підпапку та файл та додавати разом усі ці розміри.

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


-1

У мене була ця проблема з домашнім каталогом, коли я перемістив її на внутрішній жорсткий диск після встановлення Yosemite на SSD. Під час використання "Отримати інформацію" він повідомив про неправильний розмір лише 8 ГБ, хоча в рядку стану Finder показав правильний розмір 240 ГБ. Я виправив це, натиснувши Отримати інформацію в папці Користувачі, яка потім правильно розраховувалась та виправляла неправильний розмір, про який повідомляв Домашній каталог.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.