私は Win10 ノートブックを使用していますが、次のような問題が発生しています。
フォルダーを右クリック > プロパティ > 詳細設定で表示される組み込みの暗号化機能を使用して、すべてのサブフォルダーを含むフォルダーを暗号化しました。
いくつかの .cpp ファイルを含むこのフォルダーのサブフォルダーを USB ドライブ (FAT32) に移動し、そこから Linux HD (EXT3/EXT4) に移動しましたが、まだ暗号化されていることに気付きませんでした。
これらのファイルは .pfile 拡張子が付いていて暗号化されていたため、Linux PC では当然開けませんでした。そこで、これらのファイルを USB ドライブに戻し、そこから再びノートブックに移動しました。
しかし、ノートパソコンでは、もう開けません。プロパティのフックが設定されていないため、Win10 はファイルがまだ暗号化されていることにすら気付いていないようです。
Azure Information Protection-Viewer を使用してインストールしましたが、ファイルタイプ (.cpp) を開けないというエラーのみが表示されます。(英語版をインストールしていないため、英語での正確なエラー通知はわかりません)
答え1
Microsoft は、FAT32 ディレクトリ エントリ内のこれまで使用されていないフィールド、およびおそらく隠しディレクトリ エントリと長いファイル名と短いファイル名を使用したトリックを使用して、EFS メタデータを FAT32 に保存しているようです。
暗号化されたファイルには「.PFILE」拡張子が付いており、8.3 ディレクトリ エントリには追加のメタデータが格納されます。現在の実装では、このメタデータは 6 ビットに収まります。2 ビットはフラグとして使用され、4 ビットはパディング サイズの格納に使用されます。
追加のメタデータは、8.3 ディレクトリ エントリ内の 12 バイトのオフセットにある NTByte フィールドに格納されます。以前は、このフィールドは、短いベース名または拡張子を小文字としてマークする 2 つのフラグ (それぞれビット #3 と #4) を格納するためにのみ使用されていました。
ここで、残りのビットも使用されます。ビット #0 は、ファイルが暗号化されるときに設定されます (新しく作成されたファイルがデフォルトで暗号化される必要があるディレクトリに対しても設定されます)。ビット #1 は、ファイルが大きな EFS ヘッダーで始まるときに設定されます (それ以外の場合は、標準の EFS ヘッダーです)。その他のビット (ビット #2、#5、#6、#7) は、パディング サイズ (最大 15 バイトのサイズなので、4 ビットで十分です) を格納するために使用されます。ビット #0 (LSB) は NTByte フィールドのビット #2 に、ビット #1 はビット #5 に、ビット #2 はビット #6 に、ビット #3 はビット #7 になります。
（ソース、参照先も参照米国特許 US10726147B2）
ファイルを移動してから元に戻すと、Linux はそれを認識できないため、特別なメタデータが破壊されます。
申し訳ありませんが、ファイルはほぼ確実に回復不能です。それでも、隠しメタデータを推測することはできます。結局のところ、可能な値は 64 個しかありません。ただし、これを行うには、raw ディスク 16 進エディターまたはカスタム ファイル システム ドライバーが必要です。
答え2
何日も探した後、解決策を見つけました。
問題は、ファイルをLinuxにコピーして、それをコピーし直すと、ファイルのメタデータが破壊されることです。私はディスクエディタを使用してこれを解決しました。同じサイズのファイルを作成し、それを暗号化してFAT32ドライブにコピーし、削除した後のファイルのメタデータをコピーして、破壊された「.PFILE」に置き換え、メタデータを置き換えました。
ありがとう「ダニエルB」あなたの答えは本当に役に立ちました