手工修复有关的元文件大概是以下四个：
0 $MFT 描述卷上的所有文件，包括文件名、时间戳、流名称和数据流所在的簇的编号列表、索引、安全标识符，以及文件属性（如“只读”、“压缩”、“加密”等）。 1 $MFTMirr $MFT的最开始的几个关键项的副本，通常是4项（4KiB）。 2 $LogFile 文件系统更改的事务日志，用于保护元数据的稳定性。 3 $Volume 卷的相关信息，如卷对象标识符、卷标、文件系统版本，以及若干卷标志（包括：“正在加载”、“需要扫描”、“需要调整$LogFile大小”、“在NT4上加载”、“正在更新卷序列号”、“需要升级结构”等）。这些数据不直接在数据流中存储，而是存储于特殊的 MFT 属性中。如果卷对象标识符存在，则将会在一个 $OJBECT_ID 记录中；卷标存储在 $VOLUME_NAME 记录中；其它数据存储在 $VOLUME_INFORMATION 记录中；卷序列号储存在$Boot文件中（请参见下文）。
- 打开 WinHex ，必须以管理员权限运行；
- 发现 offset 的 000000000 位置显示出 NTFS 字样，说明系统文件仍是 NTFS ，只是显示成 RAW 格式而已，仅需要修复 MFT；
- 由于 offset 的数据量实在太大，手动翻找太困难，因此用 Ctrl+G 定位指定簇号，移动硬盘的存放 $MFT 的簇号一般是786432；（事实上 $MFT 发生了偏移才导致硬盘问题，因此直接选择 $MFT 定位到的位置也是不正确的，应该按照簇号定位）
- 在 offset 列对应的值是 0C0000000 ，开头的四个字节一定是 46 49 4C 45；相应的ASCII 码是 FILE 0；如果发现不是，说明发生了偏移，而这个偏移就是我们要修复的；
- 现在可以在工具里面选择打开磁盘，选择一个正常的本地磁盘，同样定位到簇号786432，再此按照刚刚的方法检视，会发现这回对应的值都对，从 0C0000000 开始，往下慢慢滚动进度条，会发现右侧的 ASCII 码 FILE 0 下方有 $MFT 字样，从这一块区域开始，存在一定规律：每当左侧对应的第一行字节出现 46 49 4C 45 开头时，右侧 ASCII 码块区中一定会新显示出一块 FILE 0 开头的 ASCII 码，然后间隔一块同样大小的空白区域后再次出现一块 FILE 0 开头的，而 ASCII 码中显示的字样依次会出现 $MFT 、空白、$MFTMirr、空白、$LogFile、空白、$Volume、空白，这几项（并不醒目）。最后一行的位置应该是 0c0000FF0 ，以上就是正常磁盘的 MFT 位置；接下来就是参照正常磁盘的数值，对移动硬盘进行 MFT 修复；如果有条件，应该移植其他相似的正常移动硬盘（同一品牌最佳）
- 因为我并没有深入了解其中原理和意义，只是单纯移植正常硬盘的数据，而毕竟移动硬盘跟本地磁盘是有些许区别的，不保证完全复原；经过查证，四个元文件中，$Volume是最重要的部分，也是导致 chkdsk 无法正确识别的原因。（ $Volume 里放的是卷关键信息，包括 NTFS 版本）因此四个元文件中优先修复 $Volume ，如果仅仅修复这里就可以执行 chkdsk ，那么剩余两个也无所谓了；
- 选择正常本地磁盘的 $Volume 区，复制从 46 49 4C 45 开始一直到最下方 0c0000FF0 这一行，也就是 ASCII 码区$Volume 及其下方空白区两个区域的数值；Ctrl+C 复制，到对应的移动硬盘同样区域光标选中，Ctrl+B 填充数据，确定，保存。退出 Winhex。
- 先别管另外的三个元文件，直接管理员权限下，WIN+R ，键入 CMD，ENTER。键入：chkdsk 目标盘符: /f 修复看看
- 事实上如果想更加保险，应该在原盘修复之前，利用 WinHex 的备份功能直接对损坏磁盘的数据进行提取备份至其他硬盘；然后再尝试原盘修复；
