Windows フォルダ内の実際のファイルサイズについて
Vistaのここがもっといやだ！
以前この記事を書いたときに、Windowsフォルダの中に WinSxS というファイルが巨大で無駄だっていう話を書いたときに、これは殆どハードリンクで実体がないという意見をいただいたという話を書き反論するなども書いたのですが、マイクロソフトからの公式の資料が出てきたので紹介します。
WinSxS フォルダーの実際のサイズの特定 - Windows 10 hardware dev
| WinSxS フォルダーは、なぜこれほど巨大なのでしょうか。このよくたずねられる質問に対する簡単な答えは、"コンポーネント ストア (WinSxS フォルダー) には、システムを操作できるように Windows を構成するすべてのコンポーネントが含まれているため" ということです。これらのコンポーネントは、問題のある変更をロールバックしたり、破損したファイルを修復したりするために保持されます。コンポーネント ストアについて詳しくは、「コンポーネント ストアの管理」をご覧ください。WinSxS フォルダーのファイルを削除する方法については、「WinSxS フォルダーのクリーンアップ」をご覧ください。
オペレーティング システム ファイルの場合は、ファイルの同じバージョンの複数のコピーがオペレーティング システムの複数の場所に格納されていることがありますが、通常はファイルの実際のコピーは 1 つだけです。その他のコピーは、コンポーネント ストアからのハード リンクによって単に "投影" されているだけです。ハード リンクは、2 つのファイルがディスク上の同じ場所を参照できるようにするファイル システム オブジェクトです。エクスプローラーのような一部のツールは、ディレクトリのサイズを判断するときに、含まれているファイルがハード リンクかもしれないということを考慮しません。そのため、WinSxS フォルダーが実際よりも多くのディスク領域を占有していると思われてしまう場合もあります。 |
これを見てわかるのは、WinSxSフォルダにあるのが実態で、
system32 に存在するのがハードリンク。
なので、WinSxS フォルダ見たときに 10G 消費されていた場合は、それが全部実際のファイルということになります。
逆に、system32 にあるファイルを削除してしまうと、 その時点でリンクされていた WinSxS ファイルまで削除してされてしまうということになります。
これを考えると、Windows 2000の魔改造パッケージで発生していたVC++2005の問題の原因がわかります。
・Windows 2000 魔改造バッケージでは VC++2005 が直接 system32 にインストールされています
・ところが、ここに VC++2005 Runtime の古いバージョンを入れると、WinSxS フォルダにコンポーネントストアファイルが導入されるだけではなく、 system32 のハードリンクが書き換えられ、元々あったファイルが消滅してしまいます。
・この状態で VC++2005 Runtime をアンインストールすると WinSxS フォルダにコンポーネントストアファイル が削除されるだけですが、system32 がハードリンクになってしまっているので、元のファイルが復元されずに、Runtime が見つからなくなってしまう
と言うわけです。
なので、次期バージョンで このメカニズムを正確に実装した上でリリースする予定です
ようやく長年の謎が解けた！
Translate
昔からあるハードリンクは最後の一箇所を削除するまでファイル本体は削除されない（それまではリンク情報だけが削除されていく）のですが、ＷｉｎＳｘＳでは動作が違うのでしょうか？
その認識であっています。
シンボリックリンクとなる最初のファイルを作る処理上の問題で
不整合が起こるのが原因のようです
まさか、上書きせずに、削除してからコピーしているとか？