首先,介绍一下该驱动器的一些信息 - 它是一个 USB 2.0 便携式硬盘 (PQI H560),一个分区占整个 640GB,NTFS。几乎只在 Linux(arch 和 ubuntu)上使用,但最初在 Windows 7 上格式化。
硬盘上有相当多的硬链接,因为它是一个类似时间机器的备份系统。
现在来谈谈问题本身:
今天我犯了一个错误,从 Linux 系统中取出便携式硬盘并将其插入 Windows 7 机箱。一切正常,我从硬盘中取出一部电影,它静置了大约一个小时。之后我取出硬盘(忘记卸载 :/)并将其放回 Linux 中。
不幸的是得到了以下错误:
[49162.611858] mount.ntfs[15397]: segfault at 7fff19cb1fe8 ip 00007f9fca88de4e sp 00007fff19cb1fa0 error 6 in libntfs-3g.so.79.0.0[7f9fca87f000+42000]
好吧,Linux 对 NTFS 的支持不太好,所以我回到 Windows 进行磁盘扫描之类的操作。是的,没错:
You need to format the disk in drive F: before you can use it.
Do you want to format it?
不,我不知道。
右键单击->工具->立即检查(那是chkdsk,对吗?):
The disk check could not be performed because Windows can't access the disk.
回到熟悉的Linux,fdisk -l
确实找到了NTFS文件系统,但我有点害怕做一个fsck
或ntfsfix
。
正如我所说,Linux 对 NTFS 的支持很欠缺。也许我会尝试将dd
分区复制到另一个驱动器并在那里进行实验,但目前我还没有硬件。
知道为什么它会损坏得这么严重吗?我以为 NTFS 还算耐用。
有关数据恢复工具的提示会很棒。最好能有一些非破坏性的东西(能够获取数据,同时保留驱动器当前状态的每一部分 - 只是为了确保它不会破坏任何东西)
答案1
不安全地移除驱动器是导致你失败的原因。
您必须运行数据恢复来删除文件、格式化驱动器并将所有内容移回,或者冒险使用其中一个 Linux 工具。
此外,Windows 7 没有任何问题。您执行了不安全的删除,所以这不是 Windows 的错误。
答案2
好吧...在运行任何工具之前,我确实建议制作一个图像...如果你没有直接制作 dd 图像的硬件,请尝试将其导入 lzma,并尽可能地压缩它:
dd if=/dev/sdb bs=512k |lzma -7 -c - >ntfs.img.lzma
您可以用任何东西代替 sdb...抱歉,如果这听起来有点居高临下,那不是故意的。从您的帖子来看,您知道 dd 的要点。如果您像我一样没有耐心,您应该将其导入 pv 并获得进度条:
dd if=/dev/sdb bs=512k |pv |lzma -7 -c - >ntfs.img.lzma
我只将 lzma 的压缩级别设置为 7,因为在较慢的处理器上,9 可能需要很长时间。一旦解决了这个问题,我推荐使用 testdisk 及其姊妹应用程序 photorec。Testdisk 在一定程度上能够修复文件系统……我自己没有用过很多,但我知道有些人对它赞不绝口。Photorec 是恢复所有单个文件的最后一搏,它会查找已知文件类型逻辑数据的开始和结束点。但是,即使它可能很耗时,您也应该先尝试 ntfsfix。如果它完全破坏了任何东西,那么只需从您的映像中提取:
unlzma -c ntfs.img.lzma |pv |dd of=/dev/sdb bs=512k
关于哪里出了问题,我只想说不要责怪任何一个操作系统,它们都对损坏它起了同等的作用。它因 Windows 操作系统未清洁而变脏,在尝试 ntfs-3g 可写入安装时,它进一步损坏,以至于 Windows 不再喜欢它。这听起来有点奇怪,但看看内核配置,ntfs 写入支持仍然被标记为实验性的,风险自负。虽然我讨厌 Windows,但这次我不能责怪它。ntfs 有点奇怪:从 Windows 未清洁卸载可以从 Windows 修复,从 linux 未清洁卸载可以从 linux 修复。使用不干净的 ntfs 分区越界通常会杀死它……抱歉,只是其中一件事。
答案3
这个问题的答案是恢复器终极版,除了一些大文件(2GB+)、日志和一些硬链接(被视为重复)的问题外,它解决了它。
此外,我越是查看日志,就越觉得 MFT 不是问题所在,至少不是 MFT 的根源。一些重复的内容不是二进制相等的,似乎是驱动器在影子复制时失败了,也许 MFT 的较深部分存在一些循环或其他非常糟糕的结构。查看日志似乎所有操作系统实现都发生了致命故障,我的意思是分段错误。MacOS X 的一个有趣日志:
Interval Since Last Panic Report: 472 sec
Panics Since Last Report: 2
Anonymous UUID: D89B5624-FF95-48B5-8F55-0987EA2D2466
Sun Jun 26 18:02:46 2011
panic(cpu 0 caller 0x6e085e4a): "ntfs_map_runlist_nolock(): Called for $MFT/$DATA!\n"@/SourceCache/ntfs/ntfs-65.5/kext/ntfs_attr.c:245
Backtrace (CPU 0), Frame : Return Address (4 potential args on stack)
...
Kernel Extensions in backtrace (with dependencies):
com.apple.filesystems.ntfs(3.4)@0x6e05a000->0x6e0b9fff
BSD process name corresponding to current thread: mount_ntfs
然后它就死了。
所以,看来我遇到了一个由懒惰引起的罕见问题。供将来参考:最好的解决方法是做你应该做的事情,即卸载驱动器。也许还可以禁用外部驱动器上的卷影复制。
无论如何,恢复程序修复了它,至于失败,看起来 Windows 以某种方式导致分区处于日志系统不应该处于的状态。也许在 Linux 中安装它也起了作用,尽管我觉得不太可能,ntfs3g 不会在没有询问的情况下修复东西,通常它无论如何都无法做到,或者在系统日志中呼吁用户注意。