Mac OS X nie zgłasza poprawnie rozmiarów katalogów?

W Finderze zauważyłem, że jeśli zduplikuję niektóre pliki .app (w folderze Aplikacje), Finder pokaże, że zduplikowany plik .app nie ma tego samego rozmiaru co oryginał. Ta rozbieżność rozmiaru pliku nie występuje w przypadku wszystkich plików .app, które powielam, ale wydaje się, że im większy plik .app, tym większe prawdopodobieństwo, że duplikat nie będzie miał tego samego rozmiaru co oryginał. Oto kilka przykładów:

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

Teraz jestem nowy na komputerach Mac i kiedy zauważyłem ten problem z rozbieżnością rozmiaru pliku, odkryłem, że pliki .app tak naprawdę nie są plikami - to tak naprawdę katalogi, ale Finder wyświetla je tak, jakby były plikami. Pomyślałem więc, że może proces kopiowania nie skopiował całej zawartości oryginalnego katalogu .app i to wyjaśnia różnicę w „rozmiarze pliku”. Ale potem pobrałem i zainstalowałem DeltaWalker, który jest narzędziem do porównywania plików / folderów, i DeltaWalker powiedział, że zduplikowane katalogi .app były dokładnie takie same jak oryginalne katalogi .app. Tak więc proces powielania działał idealnie, dlatego wydaje się, że jest to problem z rozmiarami plików raportowania Findera.

Sprawdziłem również rozmiary katalogów w Terminalu, używając polecenia „du”, co również pokazuje rozbieżności w rozmiarach między katalogami oryginalnymi i zduplikowanymi:

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/

Ponadto nie są to tylko katalogi .app. Zduplikowałem mój katalog / Developer / Library i oto, co powiedział du:

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

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

Czy ktoś może zatem wyjaśnić, dlaczego system Mac OS X nie wydaje poprawnie zgłaszać rozmiarów katalogów? Czy to błąd (trudno uwierzyć w coś tak prostego), czy też czegoś brakuje (będąc nowym użytkownikiem Maca)?

(Używam Mac OS X Lion 10.7.2)

AKTUALIZACJA w odpowiedzi na elofturtle:

Najbardziej dziwne jest to, że Finder nie ma spójności. Właśnie zrobiłem 2 duplikaty GarageBand.app, a następnie wykonałem 2 duplikaty jednego z duplikatów. Finder wyświetla każdy duplikat o innym rozmiarze:

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)

Należy również pamiętać, że „GarageBand copy 3.app” jest większy niż „GarageBand copy 2.app”, podczas gdy „GarageBand copy 4.app” jest mniejszy niż „GarageBand copy 2.app”. To musi być błąd w Finderze.

Oto, co „du -k” mówi o nich wszystkich:

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/

Przynajmniej mówi, że wszystkie duplikaty są tego samego rozmiaru, ale nie są tego samego rozmiaru co oryginał.

Różnice wynikały z różnych powodów: różnych sposobów liczenia, różnych narzędzi, kompresji i tego, co wygląda jak błąd.

Pierwsza różnica w wielkości widać wydaje się być błąd w Finderze . Rozmiary plików wyświetlane przez Findera są w jakiś sposób obliczane w czasie rzeczywistym i buforowane w .DS_Storeplikach. Z jakiegoś powodu podczas kopiowania dużej aplikacji / folderu Finder oblicza jej rozmiar podczas procesu kopiowania i buforuje rozmiar, a następnie niekompletny. Następnie pokazuje ten kolor jako szary w oknach Findera, szary, co oznacza, że Finder wie, że zawartość zmieniła się od czasu ostatniego obliczenia rozmiaru, ale jeszcze go nie przeliczył .

Jedynym sposobem, w jaki udało mi się go poprawnie przeliczyć, jest usunięcie .DS_Storepliku w folderze aplikacji, a następnie zamknięcie Findera (na przykład z Monitora aktywności) i ponowne uruchomienie go (z ikony Docka). Jeśli nie usuniesz .DS_Storepliku, nadal będzie wyszarzony. Może poczekanie czasu (godziny, dni, restart, ...) sprawi, że Finder zrobi to samo.

Następnie powinieneś zobaczyć, że wszystkie rozmiary zgłoszone przez Findera są takie same.

Tak, wygląda na błąd Findera, przynajmniej w OSX Lion (testowany tutaj z 10.7.4, wersja Finder 10.7.3). Możesz także zobaczyć ten wątek, który zgłasza takie same zachowania.

Rozważmy to dunarzędzie. Na początku myślałem, że różnicę, którą widzimy, można wyjaśnić różnicą między logicznym a fizycznym rozmiarem kopiowanych elementów. Rozmiar logiczny to rzeczywisty rozmiar elementu, co oznacza, że ​​każdy pojedynczy fragment informacji, który zawiera, jest sumowany. Rozmiar fizyczny to rozmiar elementu na dysku, w którym każdy bit informacji jest zapisywany w sektorze dysku.

Na przykład plik zawierający pojedynczy znak miałby 1 logiczny rozmiar 1 bajta, ale fizyczny rozmiar 512 bajtów, a nawet 4096 bajtów, kiedy faktycznie jest zapisywany na dysku. Rozmiar fizyczny jest zwykle większy niż rozmiar logiczny (i zależy od rzeczywistego rozmiaru sektora / bloku dysku lub systemu plików). Wyjaśnia to więcej szczegółów w tym drugim wątku . Rozmiar logiczny może być większy w przypadku plików rzadkich , ale wydaje się, że HFS + nie obsługuje takiej funkcji.

dupokazuje tylko rozmiar fizyczny (i możesz powiedzieć, co to jest BLOCKSIZE). Widoczny rozmiar dujest zawsze większy (lub wyjątkowo taki sam) jak oryginał. Wynika to z fragmentacji systemu plików i miejsca na dysku. Kiedy kopiujesz plik (w rzeczywistości tutaj kilka plików, ponieważ Aplikacja jest katalogiem), nowe sektory są przydzielane na dysk, a gdy zachodzi fragmentacja , liczba używanych bloków jest zwykle większa niż w oryginalnym elemencie. Niektórzy nazywają to zwolnieniem pliku .

Wróćmy teraz do Findera. Jeśli otworzysz okno pobierania informacji o zduplikowanych aplikacjach, zobaczysz, że Finder faktycznie zgłasza zarówno rozmiar logiczny, jak i fizyczny wybranego elementu. Co wtedy ma sens. Będziesz nawet mógł porównać rozmiar fizyczny zgłoszony przez Findera i rozmiar zgłoszony przez duciebie, jeśli wykonasz trochę matematyki.

Po co robić matematykę? Ponieważ Finder pokazuje rozmiary plików w kB, MB lub GB, gdzie duzgłasza je w kiB, MiB lub GiB. Są to binarne przedrostki IEC, których należy używać do obliczania i wyświetlania jednostek informacji cyfrowej.

Ale tak naprawdę nie jestem pewien, czy w grę wchodzi File Slack, jest coś jeszcze. Woluminy HFS + umożliwiają kompresję , wykonywaną w sposób transparentny, a Apple używa tej opcji do oryginalnych elementów zainstalowanych przez system operacyjny. Następnie, gdy pliki są kopiowane przy użyciu standardowych narzędzi, kompresja nie jest już używana (domyślnie, aby była kompatybilna wstecz). Jeśli chcesz zachować kompresję tych plików, musisz użyć dittopolecenia zamiast cplub dowolnej akcji Findera. Jest to wyjaśnione w tej recenzji .

Oto wyniki kopiowania iTunes.app przy użyciu różnych technik. Zobaczysz, że to samo sprawia, że ​​aplikacja ma dokładnie ten sam rozmiar, zachowując kompresję, a cpnie robi tego. Możesz nawet usunąć plik binarny dla łuku, którego nie potrzebujesz, a następnie zmniejszyć cały rozmiar):

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

Dzięki @DanPritts za odpowiedź na mój uzupełniający post .

Jest to okropna wada / błąd w systemie OS X. Najłatwiej to zobaczyć, kopiując duży pakiet aplikacji, a następnie wyświetlając zawartość i usuwając z niego ogromny plik. Przestrzeń nie odzyska się. Plik jest nadal ogromny. Na przykład, jeśli masz pakiet aplikacji o pojemności 3,5 GB, wyświetlasz zawartość, a następnie usuwasz z niego 3 GB, powinieneś teraz mieć aplikację o rozmiarze pliku 500 MB. Nie będziesz. Nadal będzie to 3,5 GB.

To w zasadzie zgadywanie, ale widzę dwie możliwości:

1. Niektóre dane zostały usunięte, ale nie zostały cofnięte w oryginale i nie są one kopiowane. Jednak pojawia się w niektórych wyszukiwaniach użycia dysku, ale nie w innych (różne parametry przypisane du lub dowolnemu systemowi OS X używają wewnętrznie).
2. Niektóre dane są łączone z pierwotną lokalizacją, co wpływa na postrzegany rozmiar w różnych narzędziach.

Jeśli (1) prawdopodobnie powinieneś uzyskać inne wyniki, tworząc trzecią kopię i porównując kopie.

Po pierwsze, należy pamiętać, że pliki .app dla komputerów Mac to w rzeczywistości katalogi , a nie skompilowane pliki binarne, takie jak pliki .exe systemu Windows. Finder ukrywa przed tobą ten fakt dla folderów o nazwie * .app.

np. (z terminala)

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

Jestem pewien, że to, co się dzieje, polega na tym, że Finder / Get Info korzysta z niezbyt sprytnej heurystyki, aby obliczyć rozmiar folderu .app. Oznacza to, że nie musi wyliczać każdego podfolderu i pliku ani sumować wszystkich tych rozmiarów.

Domyślam się, że oszacowanie na kopii jest poprawne, ponieważ OSX musiał ostatnio sprawdzić każdy plik w nim, kiedy zrobiłeś kopię, podczas gdy na oryginale OSX nigdy nie musiał tego robić (np. Przy instalacjach fabrycznych)

Miałem ten problem z moim katalogiem domowym, gdy przeniosłem go na wewnętrzny dysk twardy po zainstalowaniu Yosemite na dysku SSD. Podczas korzystania z funkcji „Uzyskaj informacje” zgłosił niepoprawny rozmiar wynoszący tylko 8 GB, chociaż pokazywał prawidłowy rozmiar 240 GB na pasku stanu Findera. Naprawiłem to, klikając polecenie Uzyskaj informacje w folderze Użytkownicy, który następnie poprawnie obliczył i naprawiłem nieprawidłowy rozmiar zgłaszany przez katalog domowy.