☰

Mac OS X がディレクトリのサイズを正しく報告しないのはなぜですか?

tag-icon • tag-icon macos compression hfs+
Mac OS X がディレクトリのサイズを正しく報告しないのはなぜですか?

Finder で、いくつかの .app ファイル (アプリケーション フォルダ内) を複製すると、複製された .app ファイルのサイズが元のファイルと同じではないことが Finder に表示されることに気付きました。このファイル サイズの不一致は、複製したすべての .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 に一貫性がないことです。GarageBand.app の複製を 2 つ作成し、そのうちの 1 つを複製してさらに 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/

少なくとも、複製はすべて同じサイズであると書かれていますが、元のものと同じサイズではありません。

答え1

違いは、カウント方法の違い、ツールの違い、圧縮、バグのようなものなど、さまざまな理由から生じました。

の最初の違い大きさはご覧の通りFinderのバグファインダーに表示されるファイルサイズは、何らかの方法でリアルタイムで計算され、.DS_Storeファイルにキャッシュされます。何らかの理由で、大きなアプリケーション/フォルダを複製する際、ファインダーはコピープロセス中にサイズを計算し、その不完全なサイズをキャッシュします。その後、ファインダーウィンドウでそのサイズが灰色で表示されます。灰色の意味はFinderは前回のサイズ計算以降にコンテンツが変更されたことを認識していますが、まだ再計算していません。。

サイズを正しく再計算させる唯一の方法は、.DS_Storeアプリケーションフォルダ内のファイルを削除し、Finderを終了して（たとえばアクティビティモニタから）、再度起動することです（Dockアイコンから）。ファイルを削除しないと.DS_Store、グレーのままになります。待つといいかもしれません。いつか(時間、日数、再起動など) を指定すると、Finder が自動的にそれを実行します。

その後、Finder によって報告されるすべてのサイズが同じであることがわかります。

少なくともOSX Lionでは、Finderのバグのようです（ここでは10.7.4でテスト、Finderバージョン10.7.3）。このスレッド同様の動作を報告します。

次にツールについて考えてみましょうdu。最初、この違いはコピーされるアイテムの論理サイズと物理サイズの違いによって説明できると考えました。論理サイズとは本物アイテムのサイズ、つまりそこに含まれるすべての情報ビットを合計したサイズ。物理サイズはディスク上のアイテムのサイズであり、各情報ビットはディスク セクターに書き込まれます。

例えば、1文字を含むファイルは論理サイズが1バイトになりますが、実際にディスクに書き込まれると、物理サイズは512バイトまたは4096バイトになります。物理サイズは通常、論理サイズよりも大きくなります（ディスクまたはファイルシステムの実際のセクター/ブロックサイズによって異なります）。これはこの他のスレッドでさらに詳しく説明されています論理サイズは、次の場合にはさらに大きくなる可能性があります。スパースファイルただし、HFS+ はそのような機能をサポートしていないようです。

duは物理サイズのみを表示します (BLOCKSIZE が何であるかを伝えることができます)。 によって報告されるサイズはdu常に元のサイズよりも大きい (または、例外的に同じ) ことがわかります。これは、ファイル システムとディスク領域の断片化が原因です。ファイル (実際には、アプリケーションはディレクトリであるため、ここでは多数のファイル) をコピーすると、ディスク上に新しいセクターが割り当てられ、断片化が起こると使用されるブロックの数は、通常、元のアイテムの数よりも多くなります。これをファイルSlack。

さて、Finderに戻りましょう。情報を取得複製したアプリケーションのウィンドウを見ると、Finder が実際に選択した項目の論理サイズと物理サイズの両方を報告していることがわかります。これは理にかなっています。du少し計算すれば、Finder によって報告された物理サイズと によって報告された物理サイズを比較することもできます。

なぜ計算をするのか？FinderはファイルサイズをkB、MB、GBで表示しますが、dukiB、MiB、GiBで報告するからです。IEC バイナリプレフィックスデジタル情報の単位を計算して表示するために使用されます。

しかし、実際のところ、File Slack がここに関係しているかどうかはわかりません。何か他のものがあると思います。 HFS+ボリュームは圧縮が可能は透過的に行われ、AppleはOSによってインストールされた元のアイテムにこれを使用します。その後、標準ツールを使用してファイルをコピーすると、圧縮は使用されなくなります（下位互換性のため、デフォルトでは）。これらのファイルの圧縮を維持したい場合は、またはFinderのアクションdittoの代わりに コマンドを使用する必要がありますcp。これはこのレビューで説明されている。

さまざまなテクニックを使用して 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に感謝します私の補足投稿に。

答え2

これは OS X のひどい欠陥/バグです。これを確認する最も簡単な方法は、大きなアプリケーション バンドルを複製し、コンテンツを表示して、その中の巨大なファイルを削除することです。スペースは回復しません。ファイルはまだ巨大です。たとえば、3.5 GB のアプリケーション バンドルがある場合、コンテンツを表示して 3 GB を削除すると、ファイル サイズが 500 MB のアプリケーションが作成されます。しかし、そうはなりません。サイズは 3.5 GB のままです。

答え3

これは基本的に推測ですが、2つの可能性があると思います。

  1. 一部のデータは削除されていますが、元のデータでは割り当て解除されておらず、コピーされません。ただし、一部のディスク使用量検索では表示されますが、他の検索では表示されません (du または OS X が内部で使用するものに異なるパラメータが渡されます)。
  2. 一部のデータは元の場所にリンクされ、さ​​まざまなツールで認識されるサイズに影響します。

（1）の場合、3番目のコピーを作成してそれらのコピーを比較すると、おそらく異なる結果が得られるはずです。

答え4

Yosemite を SSD にインストールした後、ホーム ディレクトリを内蔵 HDD に移動したら、この問題が発生しました。Finder のステータス バーには正しいサイズ 240 GB が表示されていたのに、「情報を見る」を使用すると、8 GB という誤ったサイズが報告されました。Users フォルダで「情報を見る」をクリックしてこの問題を修正したところ、正しく計算され、ホーム ディレクトリによって報告されていた誤ったサイズが修正されました。

関連情報