我在 Win10 笔记本电脑上遇到以下问题：
我已经使用内置加密功能加密了一个文件夹（包括所有子文件夹），您可以在右键单击文件夹 > 属性 > 高级时获得该功能。
我将该文件夹的一个子文件夹（包含一些 .cpp 文件）移动到 USB 驱动器（FAT32），然后从那里移动到 Linux HD（EXT3/EXT4），但没有意识到它仍然是加密的。
在我的 Linux PC 上，我显然无法打开这些文件，因为它们的扩展名为 .pfile，并且已加密。所以我将它们移回 USB 驱动器，然后再次移到笔记本上。
但是现在我在笔记本上也无法打开它们了。似乎 Win10 甚至没有意识到它们仍然是加密的，因为属性中的钩子不再设置了。
我已经使用 Azure Information Protection-Viewer 进行了安装，但只收到无法打开文件类型 (.cpp) 的错误。（不知道确切的英文错误通知，因为我没有安装英文版本）
答案1
看起来微软正在使用 FAT32 目录条目中以前未使用的字段，也可能使用隐藏目录条目以及使用长文件名和短文件名的技巧在 FAT32 上存储 EFS 元数据：
加密文件具有“.PFILE”扩展名，其 8.3 目录条目存储附加元数据。在当前实现中，此元数据占 6 位：两位用作标志，四位用于存储填充大小。
附加元数据存储在 NTByte 字段中，该字段位于 8.3 目录条目中的 12 字节偏移处。以前，此字段仅用于存储将短基名或扩展名标记为小写的两个标志（分别为位 #3 和 #4）。
现在，剩余的位也被使用了。当文件被加密时，位 #0 被设置（当目录中新建的文件默认应该被加密时，位 #0 也会被设置），当文件以较大的 EFS 标头开头时，位 #1 被设置（否则，它是标准的 EFS 标头）。其他位（位 #2、#5、#6 和 #7）用于存储填充大小（最多 15 个字节，因此 4 位就足够了）——其位 #0（LSB）转到 NTByte 字段的位 #2，位 #1 转到位 #5，位 #2 转到位 #6，位 #3 转到位 #7。
（来源，另请参阅参考美国专利US10726147B2）
通过移走文件然后再放回去，您已经破坏了特殊元数据，因为 Linux 对此并不知情。
很抱歉，您的文件几乎肯定无法恢复。不过，您可以尝试猜测隐藏的元数据，毕竟只有 64 个可能的值。不过，这样做需要原始磁盘十六进制编辑器或自定义文件系统驱动程序。
答案2
经过几天的搜索我找到了解决方案，
问题是，当你将文件复制到 Linux 并将它们复制回来时，文件的元数据会被破坏，我使用磁盘编辑器解决了这个问题，我创建了相同大小的文件并对其进行加密，然后将其复制到 FAT32 驱动器，并复制文件的元数据，删除它并将其替换为已破坏的“.PFILE”，并替换元数据
谢谢“Daniel B”，你的回答真的帮助了我