CMD的convert命令如何将FAT转换为NTFS而又不会丢失数据？

首先，我想区分两个截然不同的事物：

• Windows上专有技术的实现convert.exe如何处理FAT32和NTFS之间的就地文件系统转换。
• 通常，如何解决就地在两个文件系统之间进行转换的问题，而又不具有所需磁盘空间的2倍，或者两个文件系统之间的可互操作的元数据，或者其他使问题变得微不足道的细节。

对于第一个，我们主要由Microsoft来发布这些信息，因为任何访问Windows源程序的人都必须签署NDA。只有得到Microsoft法律团队的批准，它才会被释放。当然，也许有人读了这个问题，然后从泄漏的Windows源代码中获得了非法副本，并从代码中找出来了，但这是合法的灰色区域。

因此，我不会回答第一个问题，因为我没有答案。

但是，我将回答第二个问题。

文件系统的历史悠久，在许多情况下，我们都希望从一个文件系统升级到另一个文件系统，而无需擦除操作系统，重新安装或使用第二个磁盘。仅举几例：

• 在2017年，将Apple iOS设备升级到iOS 10.3的每个人都在其iDevice的内置NAND上从HFS +到APFS进行了就地文件系统升级。
• 多年来，btrfs支持使用btrfs-convert工具将文件系统从ext4升级到btrfs 。

开源fstransform程序旨在在许多不同的文件系统之间进行转换（有一些警告和限制）-它包括许多/最常见的Linux文件系统，以及令人印象深刻的NTFS！尽管它支持许多其他文件系统，但它尚不支持FAT32。

阅读其C ++代码将为您提供所需的有关在不同文件系统之间进行转换的通用算法的最详细的技术知识，即使原始文件系统作者既未计划也不设计兼容性或互操作性（源文件系统或目标文件系统均未计划或设计） ！）。

一般的过程大致如下：

• 遍历当前文件系统的文件/目录树；然后，在现有文件系统中的新普通文件中，根据当前文件系统的文件列表构造FS特定的文件表（文件列表，目录，符号链接，权限等），但格式为新文件系统。
• 根据新文件系统的数据结构重新格式化旧文件系统的数据结构和就地元数据，并更新新文件表中的指针（如果适用，指向逻辑磁盘块和偏移量）以指向重新计算的文件/ directory / permission块（使用诸如“ inodes”或“ streams”之类的通用概念，具体取决于您要从哪个文件系统转换到该文件系统）。
• 在此过程的最后，用新文件系统的元数据破坏性地覆盖原始文件系统的元数据（使用魔术数字等将文件系统标识为旧文件系统类型），并创建指向“超级块”的适当映射， “ MFT”，或文件系统初始化自身所需的任何文件系统特定的数据结构。
• 更新磁盘全局分区表（例如MSDOS格式或GPT格式），并在必要时更新用于提示分区中包含的文件系统类型的幻数（请注意：某些文件系统共享相同的幻数，因为AFAIK仅为16-位号，因此只有65,535种可能性。某些文件系统驱动程序足够聪明，可以忽略幻数并“探查”文件系统的实际数据结构，以确定该分区是否包含给定文件系统的实例。）

值得注意的是，至少最后两个步骤不是原子的; 这意味着，日记文件系统（例如NTFS，reiserfs，XFS，zfs等）的通常原子性保证不可用。如果系统崩溃，电源关闭，或者即使执行转换的用户空间程序在此过程中崩溃或挂起，文件系统也将需要数据恢复专家来恢复您的数据或恢复文件系统（旧的或新的）的完整性。在这些“破坏性”操作期间，由于该过程固有地绕过了旧文件系统的日志（为了从一个文件系统更改为日志文件，所以该过程）基础存储介质以一种不受文件系统日志备份的方式对关键数据进行破坏性覆盖。 FS到另一个文件，您无法通过用其他未知文件覆盖其核心元数据来告诉旧文件系统“安全地杀死自身”。

相比之下，实际上，要求执行数据日志记录的文件系统执行普通写入是原子的：要么是整个写入已完成，要么根本没有完成（如果日志记录区域的不完整部分写入可以回滚，则可以回退）。系统在写入过程中崩溃，这是系统BSOD或内核崩溃后启动时程序fsck或chkdsk程序的工作。）

进行就地FS转换非常冒险-就像BIOS闪存一样冒险（此外，在移动设备上，您可以通过无法启动的OS永久固定设备），因为不能保证许多操作的安全性，并且这往往需要花费很长时间才能完成，因此用户很有可能会认为操作系统已挂起，并且在转换过程中将其重新启动，或者电池供电的设备用完了电池。

为了更深入地了解如何可以做到这一点更安全与被两个文件系统的了解合作设计一个与其它之间的转换（这是，据我所知，与HFS +到的APF转换iOS上的情况下），这迷人演讲采用法医方法来弄清楚APFS到底发生了什么。它不能直接解决转换问题，但是可以从提供的信息中推断出有关转换的一些细节。

这就是说，可能永远找不到您确切的原始问题的明确答案，但是我认为提供有关就地FS转换的一般过程的大量知识应该为您提供足够的线索，以消除可能出现的神秘感成为...的过程convert.exe。

顺便说一句，我本来以为“哦，太好了，ReactOS已经实现了这个工具，我们只能查看源代码！” -不 他们尚未在ReactOS上公开实现convert.exe。如果系统上的所有用户都使用过它，则他们必须正在执行专有的MS Windows二进制文件。否则，我猜他们根本不会在ReactOS中提供此实用程序。