Mac OS X dizin boyutlarını doğru şekilde bildirmiyor mu?


17

Finder'da, bazı .app dosyalarını (Uygulamalar klasöründe) çoğaltırsam, Finder'ın yinelenen .app dosyasının orijinalle aynı boyutta olmadığını göstereceğini fark ettim. Bu dosya boyutu tutarsızlığı, çoğalttığım tüm .app dosyaları için gerçekleşmez, ancak .app dosyası büyüdükçe, çoğaltmanın orijinalle aynı boyutu göstermemesi daha olasıdır. İşte bazı örnekler:

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

Şimdi Mac'lerde yeniyim ve bu dosya boyutu tutarsızlığı sorununu fark ettikten sonra, .app dosyalarının aslında dosya olmadığını keşfettim - gerçekten dizinler, ancak Finder bunları dosya gibi gösteriyor. Bu yüzden belki çoğaltma işlemi orijinal .app dizininin tüm içeriğini kopyalamadı ve "dosya boyutu" fark açıkladı düşündüm. Ama sonra bir dosya / klasör fark aracı olan DeltaWalker'ı indirip yükledim ve DeltaWalker yinelenen .app dizinlerinin orijinal .app dizinleriyle tamamen aynı olduğunu söyledi. Bu nedenle çoğaltma işlemi mükemmel bir şekilde çalıştı ve bu nedenle Finder raporlama dosya boyutlarıyla ilgili bir sorun gibi görünüyor.

Ayrıca "du" komutunu kullanarak Terminal'deki dizinlerin boyutlarını kontrol ettim ve bu da orijinal ve yinelenen dizinler arasındaki boyutlardaki tutarsızlıkları gösterir:

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/

Ayrıca, sadece .app dizinleri değil. / Geliştirici / Kütüphane dizinimi kopyaladım ve işte şunları söyledi:

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

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

Peki herkes Mac OS X'in dizin boyutlarını neden doğru bir şekilde rapor etmediğini açıklayabilir mi? Bir hata mı (çok basit bir şeye inanmak zor), yoksa bir şey mi kaçırıyorum (yeni bir Mac kullanıcısı olarak)?

(Mac OS X Lion 10.7.2 kullanıyorum)


Elofturtle yanıt olarak GÜNCELLEME:

Bu konuda en garip olan şey Finder'ın tutarlılığı olmaması. GarageBand.app dosyasının 2 kopyasını yaptım ve daha sonra kopyalarından birinin 2 kopyasını yaptım. Finder her kopyayı farklı bir boyutta görüntüler:

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)

Ayrıca "GarageBand copy 3.app" ifadesinin "GarageBand copy 2.app" den daha büyük olduğunu, "GarageBand copy 4.app" ise "GarageBand copy 2.app" den daha küçük olduğunu unutmayın. Bu Finder'da bir hata olmalı.

"Du -k" hepsi hakkında şöyle diyor:

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/

En azından tüm kopyaların aynı boyutta olduğunu söylüyor, ancak orijinaliyle aynı boyutta değiller.


Bu hardlink ve semboller aşağı gelecek bir önsezi var ve bu .app demetleri çoğaltırken ayrı dosya kopyalarına dönüştürülecek biri veya diğeri. Bu arada, bunları aynı birim içinde mi (bölüm?) Çoğalıyorsunuz?
Spiff

Aşağıdaki cevabımda eksik bir şey var mı? Sorunuza tam bir cevap olduğu izlenimini edindim, ancak şu ana kadar sizden bir yorum gelmedi. Lütfen bana bildirir misin?
Tonin

1
Gecikme için özür dilerim. Cevabınız soruya ilgimi kaybettikten sonra geldi. Ama cevabınız mükemmel - çok ayrıntılı ve gerçekten soruma tam olarak cevap veriyor. Çok teşekkür ederim ve dosya / klasör gerçekten sıkıştırılmış olsa bile Finder'ın sıkıştırılmamış boyutlar gösterdiğini hatırlamak zorundayım.
pacoverflow

Bunu yeniden etiketleme, belki de [kopya] olarak etiketlemeliydim? - Ama diğer hangi etiket pahasına?
Arne Stenström

Yanıtlar:


13

Farklılıklar farklı nedenlerden kaynaklandı: farklı sayma yolları, farklı araçlar, sıkıştırma ve hataya benzeyen şey.

İlk fark Gördüğünüz boyutunda bir gibi görünüyor Finder hata . Finder tarafından gösterilen dosya boyutları bir şekilde gerçek zamanlı olarak hesaplanır ve .DS_Storedosyalarda önbelleğe alınır . Bazı nedenlerden dolayı, büyük bir uygulamayı / klasörü çoğaltırken Finder, kopyalama işlemi sırasında boyutunu hesaplar ve ardından eksik olan boyutu önbelleğe alır. Daha sonra bu boyutu Finder pencerelerinde gri olarak gösterir, gri , Finder'ın içeriğin son boyut hesaplamasından bu yana değiştiğini bildiğini, ancak henüz yeniden hesaplamadığını gösterir .

Boyutu doğru bir şekilde yeniden hesaplayabilmemin tek yolu .DS_Store, Uygulama klasöründeki dosyayı sildikten sonra Finder'dan (örneğin Etkinlik İzleyicisi'nden) çıkıp tekrar (Dock Simgesinden) yeniden başlatmaktır. .DS_StoreDosyayı silmezseniz, hala gri renkte kalır. Belki biraz beklemek (saat, gün, yeniden başlatma, ...) Finder'ın kendi başına yapmasını sağlar.

Bundan sonra, Finder tarafından bildirilen tüm boyutların aynı olduğunu görmelisiniz.

Yani evet, en azından OSX Lion'da bir Finder hatası gibi görünüyor (burada 10.7.4 ile test edildi, Finder sürüm 10.7.3). Aynı tür davranışları bildiren bu konuyu da görebilirsiniz .

Sonra duaracı ele alalım . İlk başta gördüğümüz farkın, kopyalanan öğelerin mantıksal ve fiziksel boyutları arasındaki farkla açıklanabileceğini düşündüm. Mantıksal boyut, öğenin gerçek boyutudur, yani içerdiği her bir bilgi biti birlikte eklenir. Fiziksel boyut, her bilgi bitinin bir disk sektörüne yazıldığı diskteki öğenin boyutudur.

Örneğin, tek bir karakter içeren bir dosya 1 bayt mantıksal boyuta, ancak diske gerçekten yazıldığında 512 bayt hatta 4096 bayt fiziksel boyuta sahip olur. Fiziksel boyut genellikle mantıksal boyuttan daha büyüktür (ve diskin veya dosya sisteminin gerçek kesim / blok boyutuna bağlıdır). Bu, diğer konu başlığında daha ayrıntılı olarak açıklanmaktadır . Seyrek dosyalar söz konusu olduğunda mantıksal boyut daha büyük olabilir , ancak HFS + böyle bir özelliği desteklemiyor gibi görünmektedir.

duyalnızca fiziksel boyutu gösterir (ve bir BLOCKSIZE'ın ne olduğunu söyleyebilirsiniz). Tarafından bildirilen boyutun duher zaman orijinalden daha büyük (veya istisnai olarak aynı) olduğunu görebilirsiniz. Bunun nedeni dosya sistemi ve disk alanı parçalanmasıdır. Bir dosyanın üzerine kopyaladığınızda (aslında burada bir uygulama bir dizin olduğu için bir grup dosya) diskte yeni sektörler ayrılır ve parçalanma oluştuğunda , kullanılan blok sayısı genellikle orijinal öğeden daha fazladır. Bazı insanlar buna Dosya Slack der .

Şimdi, Finder'a geri dönelim. Çoğalttığınız Uygulamaların bilgi alma penceresini açarsanız, Finder'ın seçtiğiniz öğenin hem Mantıksal hem de Fiziksel boyutunu bildirdiğini görürsünüz. Bu daha sonra mantıklı. Bulucu tarafından bildirilen Fiziksel boyutu ve dubiraz matematik yaparsanız bildirilen fiziksel boyutu bile karşılaştırabilirsiniz .

Neden biraz matematik yapıyorsun? Çünkü Finder dosya boyutlarını kB, MB veya GB olarak gösterir, burada dukiB, MiB veya GiB olarak rapor eder. Bunlar, dijital bilgi birimlerini hesaplamak ve görüntülemek için kullanılması gereken IEC ikili önekleridir .

Ama aslında, File Slack'in burada yer aldığından emin değilim, başka bir şey var. HFS + birimleri , saydam olarak yapılan sıkıştırmaya izin verir ve Apple, işletim sistemi tarafından yüklenen orijinal öğeler için bunu kullanır. Ardından, dosyalar standart araçlar kullanılarak kopyalandığında, sıkıştırma artık kullanılmaz (varsayılan olarak geriye dönük uyumlu olmak için). Bu dosyalar üzerinde sıkıştırmayı korumak istiyorsanız, Bulucu eylemi dittoyerine komutu kullanmanız gerekir cp. Bu, bu derlemede açıklanmıştır .

İşte farklı teknikleri kullanarak iTunes.app kopyalamanın çıktısı. Ditto'nun Uygulamayı tam olarak aynı boyutta yaptığını, sıkıştırmayı koruduğu ve görmediğini göreceksiniz cp. Ve ihtiyacınız olmayan kemer için ikiliyi bile kaldırabilir, ardından tüm boyutu azaltabilirsiniz):

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

Onun cevabını @DanPritts sayesinde benim tamamlayıcı yayında .


Bunun tersi değil mi? Bulucu gerçek SI öneklerini gösterir.
Daniel Beck

Seyrek dosyalar ( seyrek paketler / OS X görüntüleri değil ) fiziksel dosya boyutundan daha mantıklı olmaz mı?
Daniel Beck

Evet, haklısın, Finder SI öneklerini ve duIEC'yi gösteriyor, yazımı düzeltirim.
Tonin

@DanielBeck Seyrek dosyalar, teorik olarak, evet, ama bir OSX uygulamasının seyrek dosyalar olarak ne tür dosyaları olurdu? Vikipedi'ye göre , HFS + 'da seyrek dosyalar desteklenmemektedir.
Tonin

Bu paragraf genellikle uygulanabilir gibi görünüyor ( diskin veya dosya sisteminin gerçek sektöre / blok boyutuna bağlıdır ), bu yüzden bundan bahsetmek istedim.
Daniel Beck

1

OS X'te korkunç bir hata / hata. Bunu görmenin en kolay yolu büyük bir uygulama paketini çoğaltmak, sonra içeriği göstermek ve içeriden büyük bir dosyayı silmek. Alan iyileşmeyecek. Dosya hala çok büyük. Örneğin, 3,5 GB'lık bir uygulama paketiniz varsa, içeriği gösterir ve ardından 3 GB'ı kaldırırsanız, artık dosya boyutu 500 MB olan bir uygulamanız olmalıdır. Yapmayacaksın. Hala 3.5GB olacak.


Boyutları yeniden hesaplamak için klasör görünümü seçeneklerinde Tüm Boyutları Hesapla'yı seçin. Bkz. Apple.stackexchange.com/a/227173/156178
asmaier

0

Bu temel olarak bir tahmindir, ancak iki olasılık görüyorum:

  1. Bazı veriler silindi, ancak orijinalde yeniden konumlandırılmadı ve bu kopyalanmıyor. Yine de bazı disk kullanım aramalarında görünür, ancak diğerlerinde görünmez (du'ya veya OS X'in dahili olarak kullandığı her ne olursa olsun farklı parametreler verilir).
  2. Bazı veriler orijinal konuma bağlanır ve bu, farklı araçlarda algılanan boyutu etkiler.

Eğer (1) ise üçüncü bir kopya çıkartarak ve kopyaları karşılaştırarak muhtemelen farklı sonuçlar almalısınız.


Maalesef, bir yorumda doğru görünmek için çok satırlı kod blokları alamıyorum, bu yüzden orijinal yazımı düzenlemeyi deneyeceğim.
pacoverflow

Yinelemelerin orijinalinden daha büyük olmasını beklemezdim: - / Bir hata raporuna layık görünüyor, ancak Finder'ın iç işleyişine ilişkin herhangi bir geri bildirim alma şansının ince olmasına neden oluyorum. Umarım buna bir göz atarlar.
elofturtle

0

Öncelikle, Mac .app dosyalarının aslında Windows .exe dosyaları gibi derlenmiş ikili dosyalar değil, Dizinler olduğunu bilmeniz gerekir . Finder bu gerçeği * .app adlı klasörler için sizden gizler.

örneğin (Terminalden)

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

Neler olduğuna eminim. Finder / Get Info, .app klasörünün boyutunu hesaplamak için çok akıllı olmayan bir buluşsal yöntem kullanıyor. Bu, her bir alt klasörü ve dosyayı numaralandırmaya ve tüm bu boyutları bir araya getirmeye gerek olmadığı anlamına gelir.

Benim tahminim, kopyadaki tahminin doğru olması, çünkü OSX, kopyayı yaptığınızda içindeki her dosyayı incelemek zorunda kalırken, orijinalinde OSX'in bunu yapmak zorunda kalmayabilir (örneğin fabrika kurulumlarında)


-1

SSD'ye Yosemite'i yükledikten sonra dahili bir HDD'ye taşıdıktan sonra Giriş Dizini ile bu sorunu yaşadım. 'Bilgi Al' kullanırken, Finder'ın durum çubuğunda 240GB'lık doğru boyutu göstermesine rağmen, sadece 8GB'lık yanlış bir boyut bildirdi. Kullanıcılar klasöründe Bilgi Al'ı tıklatarak düzelttik, sonra da doğru bir şekilde hesaplandı ve Ana Dizin tarafından bildirilen yanlış boyut düzeltildi.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.