CMDのconvertコマンドはどのようにしてデータを失うことなくFATをNTFSに変換できますか？

Question

私がしばらく疑問に思っていた何か。 Windowsでは、 convert コマンドはFAT16またはFAT32ディスクを非破壊的に（つまり、データを失うことなく）NTFSに変換できます。

convert X: /fs:ntfs

Windowsがこれをどの程度正確に行うかについての技術的な詳細は何ですか？ディスク上のデータを消去せずにディスクのファイルシステムを変換するために何をしているのでしょうか。また、他のファイルシステムにも同じ原則を適用するのでしょうか。

NTFSはプロプライエタリなファイルシステムであるため、詳細はMicrosoft自身だけが知っている可能性があることを理解していますが、NTFSがこれに関するドキュメントを公開したのか、それとも他の誰かがWindows/CMDを選択して見つけたのか疑問に思いました。

次の質問は exFATからFAT32 について話しますが、それはまったく異なるファイルシステムに関係し、まったく異なる答えを持つまったく異なる質問です。

繰り返しになりますが、ディスクのデータを消去せずにディスクのファイルシステムを変換するためにconvertが何をしているのか、そして同じ原則を他のファイルシステムで適用できるかどうかを特に知りたいと思います。

allquixotic · Accepted Answer

まず、2つの非常に異なるものを区別したいと思います。

どのようにWindowsでの独自のconvert.exeの実装は、FAT32とNTFSの間のこのインプレースファイルシステム変換を処理します。
一般に、2倍の必要なディスク容量、2つのファイルシステム間の相互運用可能なメタデータ、または問題を些細なものにするその他の優れた機能を使用せずに、2つのファイルシステム間でインプレースで変換する問題にどのように取り組むか。

1つ目は、Windowsのソースにアクセスできる人は誰でも、NDAに署名する必要があるため、その情報を公開するのはほとんどMicrosoftに翻弄されています。 Microsoftの法務チームによって承認された場合にのみリリースされます。確かに、この質問を読んでいる誰かが、リークされたWindowsソースの違法コピーを入手し、コードからこれを理解したのかもしれませんが、それは合法的な灰色の領域です。

ですから、答えがないので、最初の質問に答えようとはしません。

ただし、2番目の質問には答えます。

ファイルシステムの歴史には、OSをワイプしたり、再インストールしたり、2つ目のディスクを使用したりせずに、あるファイルシステムから別のファイルシステムにアップグレードしたいという多くのケースがありました。いくつか例を挙げると：

2017年、everyoneAppleiOSデバイスをiOS10.3にアップグレードすると、iDeviceでHFS +からAPFSへのインプレースファイルシステムアップグレードが行われました。内蔵NAND。
何年もの間、btrfsは、 btrfs-convert ツールを使用して、ファイルシステムをext4からbtrfsにインプレースでアップグレードすることをサポートしてきました。

オープンソース fstransform プログラムは、多くの異なるファイルシステム間で変換することを目的としています（いくつかの警告と制限があります）-そしてそれは多くを含みます/最も一般的なLinuxファイルシステム、そして印象的なことに、NTFS！他の非常に多くのファイルシステムをサポートしているにもかかわらず、FAT32はまだサポートしていません。

そのC++コードを読むと、互換性や相互運用性が元のファイルシステムの作成者によって（ソースファイルシステムでも宛先ファイルシステムでも）計画も設計もされていない場合でも、異種ファイルシステム間の変換に関連する一般的なアルゴリズムについて必要な最も詳細な技術知識が得られます。！）。

一般的なプロセスは、大まかに言えば、次のようになります。

現在のファイルシステムのファイル/ディレクトリツリーをウォークします。そして、既存のファイルシステム内の新しい通常のファイルで、現在のファイルシステムのファイルのリストに基づいて、FS固有のファイルテーブル（ファイル、ディレクトリ、シンボリックリンク、アクセス許可などのリスト）を作成します。ただし、newファイルシステムの形式です。
新しいファイルシステムのデータ構造に関して古いファイルシステムのデータ構造とインプレースメタデータを再フォーマットし、新しいファイルテーブル内のポインターを（該当する場合は論理ディスクブロックとオフセットに）更新して、再計算されたファイルを指すようにします。/directory/permissionブロック（「inodes」や「streams」などの一般的な概念を使用します。これは、変換元/変換先のファイルシステムによって異なります）。
プロセスの最後に、元のファイルシステムのメタデータ（マジックナンバーなどを使用してファイルシステムを古いファイルシステムタイプとして識別する）を新しいファイルシステムのメタデータで破壊的に上書きし、「スーパーブロック」を指す適切なマップを作成します。「MFT」、またはファイルシステムがそれ自体を初期化するために必要なファイルシステム固有のデータ構造。
Disk-globalを更新しますパーティションテーブル（MSDOS形式またはGPT形式など）パーティション内に含まれるファイルシステムタイプを示唆するマジックナンバーを更新します必要に応じて（注：特定ファイルシステムは同じマジックナンバーを共有します。これは、AFAIKが16ビットのナンバーしかないため、65,535の可能性しかないためです。また、一部のファイルシステムドライバーは、マジックナンバーを無視し、ファイルシステムの実際のデータ構造を「プローブ」して、そのパーティションには、特定のファイルシステムのインスタンスが含まれています。）

少なくとも、最後の2つのステップはアトミックではないことは注目に値します。つまり、ジャーナルファイルシステム（NTFS、reiserfs、XFS、zfsなど）の通常の原子性保証は利用できません。システムがクラッシュしたり、電源がオフになったり、変換を実行しているユーザースペースプログラムがクラッシュしたり、このプロセス中にハングしたりした場合でも、ファイルシステムでは、データを復元するか、ファイルシステムの正常性を復元するためにデータ復旧の専門家が必要になります（古いまたは新しい）。これらの「破壊的な」操作中に、基盤となるストレージメディアは、古いファイルシステムのジャーナルを本質的にバイパスするプロセスのために、ファイルシステムジャーナルによってバックアップされない方法で重要なデータの破壊的な上書きを行います（1つから変更するため） FS別の言い方をすれば、古いファイルシステムに、コアメタデータを知らないもので上書きして「安全に自殺する」ように指示することはできません）。

対照的に、データジャーナリングを実行するファイルシステムにordinary書き込みを実行するように要求することは、実際にはアトミックです。書き込み全体が完了するか、まったく実行されない（ジャーナルへの不完全な部分書き込み）。書き込みの途中でシステムがクラッシュした場合、領域をロールバックできます。これは、システムのBSODまたはカーネルパニック後の起動時にfsckまたはchkdskプログラムが実行することです。）

インプレースでのFS変換を行うことはかなり危険です-多くの安全性のために、BIOSフラッシュと同じくらい危険です（モバイルデバイスでは、起動できないOSを使用してデバイスを永続的にブリックできます）。動作は保証されておらず、時間がかかる傾向があるため、変換中にOSがハングして電源を入れ直したり、バッテリー駆動のデバイスのバッテリーが不足したりする可能性が高くなります。

これをどのように行うことができるかについてのより深い洞察のためにより安全ある2つのファイルシステムの協力を知って設計一方から他方に変換する（これは私が理解しているように、 iOSでのHFS +からAPFSへの変換の場合）、この魅力的な話は、APFSで一体何が起こっているのかを理解するための法医学的アプローチを取ります。変換の問題に直接取り組むわけではありませんが、提供された情報から変換に関するいくつかの詳細を推測できます。

つまり、元の質問に対する明確な答えが見つからない可能性がありますが、インプレースFS変換の一般的なプロセスについて多くの知識を提供することで、次のことについて十分な手がかりが得られると思います。 可能性が高いがconvert.exeのプロセスであるとは何かをわかりやすく説明します。

ところで、私は当初、「ああ、素晴らしい、ReactOSはすでにこのツールを実装していて、ソースコードを表示できるだけだ」と思っていました。 -いいえ。ReactOSでオープンにconvert.exeを実装していません。システム上のいずれかのユーザーが使用する場合は、独自のMSWindowsバイナリを実行している必要があります。そうでなければ、ReactOSでこのユーティリティを提供していないだけだと思います。

Ignacio Vazquez-Abrams · Answer

convertの動作に関するヒントがいくつかあります。

FATまたはFAT32からNTFSに変換されたボリュームの場合：
既存のディスク使用量のため、MFTは元々NTFSでフォーマットされたボリュームとは異なる場所に作成されます[...]たとえば、MFTは変換されたボリュームで断片化される可能性があります。

ソース

Convert.exeを使用するには、ドライブまたはパーティションに変換するための空き領域が必要です。 Convert.exeがボリュームに十分な空き領域がないと判断した場合、ボリュームは変換されません。

ソース

これらから、これがプロセスであると推測することができます。

「人工」MFTは、既存のFATまたはファイルに干渉しないように、空きFATブロックのどこかに作成されます。
ボリューム内の空きFATブロックはNTFSブロックに変換されます。
ファイルはFATブロックからNTFSブロックに移動され、FATからMFTに移動されます。
すべてのファイルが変換されるまで、手順2と3が繰り返されます。
FATが占めるスペースはNTFSブロックに変換されます。
パーティションのメタデータは、ボリュームがFATではなくNTFSになったことを示すように書き換えられます。