Mac OS Xはディレクトリサイズを正しく報告しませんか？

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

今、私はMacを初めて使い、このファイルサイズの不一致の問題に気づいた後、.appファイルは実際にはファイルではないことを発見しました。実際にはディレクトリですが、Finderはそれらをファイルのように表示します。そのため、複製プロセスでは元の.appディレクトリのすべてのコンテンツがコピーされず、「ファイルサイズ」の違いを説明できたのではないかと考えました。しかし、その後、ファイル/フォルダーdiffツールである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 -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/

少なくとも、すべての複製は同じサイズですが、元のサイズと同じではないということです。

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

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

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

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

そのため、少なくともOSX Lion（ここでは10.7.4、Finderバージョン10.7.3でテスト済み）では、Finderのバグのように見えます。また、同じ種類の動作を報告するこのスレッドを見ることができます。

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

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

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

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

なぜ数学をするのですか？FinderにはファイルサイズがkB、MB、またはGBで表示されdu、kiB、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が私の補完的な投稿についての回答をありがとう。

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

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

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

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

まず、Macの.appファイルは実際にはディレクトリであり、Windowsの.exeファイルのようなコンパイルされたバイナリではないことに注意する必要があります。Finderは、*。appと呼ばれるフォルダーについては、この事実をあなたから隠します。

例（ターミナルから）

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

何が起こっているのかは、Finder / Get Infoが非常に巧妙でないヒューリスティックを使用して.appフォルダーのサイズを計算していることだと確信しています。つまり、すべての単一のサブフォルダーとファイルを列挙し、それらすべてのサイズを合計する必要はありません。

私の推測では、OSXは最近コピーを行ったときにその中のすべてのファイルを検査しなければならなかったので、コピーの推定は正しいと思います。

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