inodeテーブルに格納されているファイルサイズと比較してファイルが切り捨てられないようにする方法はありますか？ （dd命令は使用できますか？）

したがって、最初にここに関連する信頼できないファイルシステムは、ターゲットファイルシステムではなく元のファイルシステムとして見えます。ソースが不明なコンテンツを読み取ると、その不明なコンテンツがターゲットファイルに「正しく」書き込まれ、その後は何もできません。すべての情報について、元のファイルの外観は次のとおりです。

いいえ、じゃあ始めましょう。あなたのユースケース書き込み側のあらゆる形式のデータ破損を排除します。いずれにせよ、読み取ったデータが破損しています。

それから：

NTFSファイルシステムテーブルのファイルサイズ情報を保存します。

これは、ファイルシステム間のコピーが機能する方法ではありません。ソースファイルの内容を上書きしながらターゲットファイルを作成します（readソースファイルを指定してターゲットwriteファイルを指定するか、copy_file_rangeシステムコールを介して）、メタデータはターゲットファイルシステム自体によって維持および構成されます。何もない元のファイルについて。いいえ、そんなことは起こりません。

ファイルをコピーした後、実際にコピーされたコンテンツの実際のサイズはinodeテーブルに反映されませんか？ （ファイルエクスプローラでクリックしてドラッグするだけだと思います）？

いいえ、または: 非常に、非常に可能性が低いです。 ext4では、メタデータ（実際のデータを除くすべて）が実際に記録されます。つまり、メタデータは完全に変更されたり、まったく変更されたりしません。

ext4の場合、メタデータに関連するデータを記録する基本モードは次のとおりですdata=ordered（参考資料を参照man ext4）。これは、メタデータが更新される前にデータがファイルシステムに完全に書き込まれることを意味します。だから一つはできるたとえば、システムの電源が切れると、データが書き込まれたがメタデータがまだ書き込まれていない場合が発生します。これはファイルサイズに影響します。少ないコピーされた以上のものではありません。

したがって、データはメタデータの前に記録されており、メタデータが正確であるため、データが正しいと確信できます。 （再び、ソースのデータが破損している場合は、ガベージイン、ガベージアウトは引き続き適用されます。）

ddコマンドを使用するのは良い選択ですか？

いいえ。これは、すべてのプログラムがファイルシステムによって提供されるデータ量と同じくらい正確にインポートされるためです。ファイルシステムの場合以前は破損しているファイルが長いと誤って考える、これ一部データの属性を誤って指定することで、ddよりスマートになりません。メタデータにアクセスできるためではなく、キャッチしようとしているエラーが関心のある誰にもエラーが存在しないように見えるからですdd。

ファイルサイズを独立して確認し、それに応じてinodeテーブルの情報の正確性を確認するために使用できるメタデータはext4ファイルシステムにあります（データ整合性フィールドを考えています）。

いいえ、ファイルシステムのメタデータの2番目のコピーを望まない限り、これは正確さを必要とします。

上記のように、Ext4はメタデータの書き込みが完了または発生しないことを保証するジャーナリングファイルシステムです。