web-dev-qa-db-ja.com

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

Finderで、（アプリケーションフォルダー内の）.appファイルを複製すると、複製された.appファイルが元の.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ディレクトリの内容のすべてがコピーされなかったのではないかと思ったため、「ファイルサイズ」の違いが説明されました。しかし、それからファイル/フォルダの差分ツールである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への応答としてのUPDATE：

これについて最も奇妙なのは、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/

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

macoscompressionhfs+
18
pacoverflow

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

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

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

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

だから、はい、それは少なくともOSX LionでFinderバグのように見えます（ここで10.7.4でテスト済み、Finderバージョン10.7.3でテスト済み）。同じ種類の動作を報告する this thread も確認できます。

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

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

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

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

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

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

これは、さまざまな手法を使用してiTunes.appをコピーした場合の出力です。 dittoはアプリケーションをまったく同じサイズにし、cpが圧縮を保持しないことがわかります。また、不要なArchのバイナリを削除して、全体のサイズを小さくすることもできます）：

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の回答に感謝 私の補足記事 。

13
Tonin

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

1
user245308

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

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

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

0
elofturtle

まず、Macの.appファイルは実際にはDirectoriesであり、Windowsの.exeファイルのようなコンパイル済みのバイナリではないことに注意する必要があります。 Finderは、*。appと呼ばれるフォルダに対して、この事実を隠します。

例えば（ターミナルから）

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

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

私の推測では、OSXはコピーを行ったときにその中のすべてのファイルを検査する必要があったため、コピーの推定値は正しいのですが、元のOSXでは検査する必要がなかった可能性があります（たとえば、工場出荷時のインストール）

0
Henry Collingridge