在 NTFS 分区调整大小期间 gparted 冻结

Question

如标题中所述，Gparted 在将 NTFS 分区向左移动并增加其大小以填充其右侧的磁盘空间的过程中冻结。

它执行的最后一个操作是移动块大小为 16Mb 的扇区。

有什么办法可以让它恢复移动或手动完成其余的工作？有关我的意思的示例，请参阅此帖子：http : //gparted-forum.surf4.info/viewtopic.php?pid=25907#p25907

编辑：我现在发现了以下信息：

• 复制操作被中断的确切扇区是 no。2,529,216,511。
• 根据磁盘的 MBR，分区的第一个扇区是从磁盘开始算起的 202,390 MiB，长度为 1,705,337 MiB - 这就是我应该得到的结果。
• NTFS 分区中的扩展 BPB 声称该分区的大小为 1,293,319 MiB。这是错误的，大概应该在复制完成后更新。

Answer 1

好的，所以我终于解决了这个问题！

如果 GParted 执行相同的“直接复制”，则此解决方案也适用于其他文件系统。显然，您需要使用除chkdsk最后之外的其他内容。

无论如何，这是解决问题的程序，以使像我这样不幸/愚蠢*的人受益：

1. 在开始之前，放松一下- 去喝杯咖啡或一杯热巧克力吧！

   您的数据仍在磁盘上，您只需查找它。花时间冷静地检查事情不会伤害你。冲动和冲动可能。

2. 通读一遍，确保你理解每一步。如果您随后决定按照这些说明进行操作，最好使用dd. 犯错很容易，备份会给你一个安全网。

3. 确保记下有关 GParted 所做的最后一件事的任何信息。您会想知道复制操作进行了多远（尽可能精确）以及它向后/向前复制内容的距离。

4. 找出复制完成的确切位置。我已经编写了两个 Python 脚本来帮助解决这个问题，但它们只在 ubuntu 上进行了测试（在 Windows 中肯定不起作用）并且需要针对您的特定情况进行修改。

   • 首先使用它来查找磁盘上的单个匹配扇区：findDuplicateSector.py

   • 然后用这个找到最后匹配的扇区（即操作被中断的地方）：findCopyInterruptLocation.py

   • 阅读代码并确保您理解它。我已经对其进行了简短的测试，但可能存在错误。给出的所有数字都是从分区/文件开始的绝对偏移量，即偏移量 0 是分区中的第一个扇区，偏移量 n 是第 n+1^个扇区。

5. 使用dd或类似的东西来完成复制操作，注意不要混淆输入和输出偏移。以下是语法dd：

   sudo dd bs=512 skip=<input_offset> if=<partition> seek=<output_offset> of=<partition> count=<num_sectors_to_copy>
   

   这一步需要很长时间（我花了8个小时）。如果您想查看它的进展情况，请在单独的终端中运行它，并dd在其自己的终端窗口中为您提供有关其进度的更新：

   sudo kill -s USR1 <PID_of_dd>
   

6. 检查以下内容并在必要时更正：

   • 主引导记录 (MBR) 的分区表条目应与您告诉 GParted 执行的操作相匹配（请参阅维基百科文章，内容非常丰富）。具体检查分区第一个扇区的LBA值及其扇区总数。

   • 您正在修改的分区的分区引导记录应该与 MBR 匹配（在我的情况下它没有）。对于 NTFS，扇区中的总分区大小应位于距分区开头 40 的偏移处。我不认为 N​​TFS 记录分区相对于磁盘开始的偏移量是多少。

7. 运行chkdsk 在只读模式，即以比驱动器名称等任何命令行参数来检查它是否可以在该分区中的所有文件。如果它无法验证文件索引，则不要继续。如果它抱怨 $Bitmap 文件包含错误，请不要担心。

8. 当且仅当第 5 步成功时，运行chkdsk /f以修复例如 $Bitmap 文件。如果你在文件索引仍然错误的时候运行它，它最终可能会删除它们，让你的事情变得更加困难。

9. 您可能希望chkdsk再次以只读模式运行以确保它有效，只是为了让您安心。

_{*其实我太嚣张了——我们不傻。但说真的 -做备份！}