| ■95429 / inTopicNo.2) |
Re[1]: ファイルサイズ情報を編集することってできますか？ |
□投稿者/ 魔界の仮面弁士 (2797回)-(2020/08/01(Sat) 17:52:15)
|
■No95426 (焚かし さん) に返信
> 分類:[.NET 全般]
ツール類を使った操作の話ではなく、プログラミングの話ですか?
> 一方で、見かけ上のファイルサイズも書き換えることができるのでしょうか？
…質問の意図が読み切れなかったのですが、.vhdx をフォルダーにマウントして使っているような場合、
ホスト側にとっての vhdx サイズと、ゲスト側から見た総サイズは合致しないですね。
それと、KB, MB, GB 等の端数計算の違いから、エクスプローラー上の表示と、
ファイルのプロパティの表示とでは、幾許かの表示誤差があります。
知的好奇心的な話なのか、それとも何らかの理由で実際のファイルサイズを偽装する必要が
生じているのか、状況が良くわからなかったので、"XY problem" に陥らないためにも、
何のためにその書き換え処理を必要としているのか、質問の背景を提示された方が良いと思います。
ひとまず、管理者コマンドプロンプトで「fsutil fsinfo volumeinfo C:」としたときに、
そのファイルシステムが何と何をサポートしているのかでも、打てる手は変わってきそうです。
> 一方で、見かけ上のファイルサイズも書き換えることができるのでしょうか？
> 例えば、1GBのファイルなのに、Explorer上で見ると0.5GBに見えるようなファイルって作成できますか？
そもそも、ファイルシステム上の消費サイズと、そこに書き込まれている
実際のファイルサイズは、必ずしも一致していませんよね。
身近な所では、アロケーションユニットサイズ単位で書き込まれるが故に、
実際のファイルサイズ以上に、ディスク上のサイズが多く消費されているパターンは
しばしば目にしているはずです。クラスタサイズが大きいほど、この差は顕著になりますね。
その逆に、ディスク上のサイズがファイルサイズよりも小さくなるパターンもあります。
たとえば、ファイルのプロパティで圧縮属性を付与しておいた場合などです。
あるいはスパースファイルでも、ディスクを消費しないまま巨大なファイルが配置されます。
また、新規作成したファイルのデータ量が小さい(数百バイト未満)場合は、
ファイル本体の情報もマスターファイルテーブルのみで保持されるため、
ディスク上のクラスタ消費が 0 バイトとして表示されることになります。
このほか、同じバイナリが複数のフォルダーにあった場合、NAS や Server 2012 などの
重複削除機構によって、実際のサイズ消費がファイル 1 個分だけで済むケースもあります。
ファイルのプロパティの「ディスク上のサイズ」にすら検知されないパターンも
ありますね。代替データストリームに付加情報が格納されているケースです。
OneDrive 等のクラウドストレージを用いている場合、エクスプローラー上では
本来のファイルサイズが表示されたままでありながらも、ローカルディスク上の
サイズ消費が 0 のままとなっているケースも、最近は増えているかと思います。
とりあえず NTFS ファイルシステムの場合の構造概要。
https://milestone-of-se.nesuke.com/sv-basic/windows-basic/ntfs-filesystem-structure/
|
|