First, some info on the drive - it's a USB 2.0 portable hard drive (PQI H560), one partition spanning all 640GB, NTFS. Used almost exclusively on Linux (arch and ubuntu), but initially formatted on Windows 7.

The hard drive has quite a lot of hard links on it, as it was a timemachine-like backup system.

And now the issue itself:

Today I made the mistake of taking out my portable hard drive from my Linux system and plugging it in a Windows 7 box. Everything worked nice, I took a movie from the drive, and it lay dormant for an hour or so. After that I took the drive out (forgot to unmount :/) and put it back in my Linux.

Unfortunately got the following error:

[49162.611858] mount.ntfs[15397]: segfault at 7fff19cb1fe8 ip 00007f9fca88de4e sp 00007fff19cb1fa0 error 6 in libntfs-3g.so.79.0.0[7f9fca87f000+42000]

Ok, Linux NTFS support isn't too good, so I went back to Windows to do a scandisk or something. Yea, right:

You need to format the disk in drive F: before you can use it.

Do you want to format it?

No, I don't.

Right-click-> Tools -> Check now (thats chkdsk, right?):

The disk check could not be performed because Windows can't access the disk.

Back to the familiar Linux, fdisk -l does find NTFS filesystem, but im a bit afraid to do an fsck or ntfsfix.

As I said, Linux NTFS support is well, lacking. Perhaps will try to do a dd of the partition to another drive and experiment there, but currently I haven't got the hardware for that.

Any idea why did it break so bad? I thought NTFS was kind of durable.

Tips on data recovery utils would be great. Best if there would be something nondestructive (be able to get the data while preserving every bit of the drive in it's current state - just to be sure it doesn't break anything)

  • 2
    I've cleaned up your question to remove the unnecessary negative comments about Windows. – user3463 Jun 5 '11 at 21:58
  • BTW: Don't be so quick to blame Windows. while it's perfectly likely that the unsafe removal caused this, Linux's NTFS support is also pretty flaky in my experience (although I'm sure Linux fans will jump here to claim the opposite). It's hard to judge anything here, so don't jump to conclusions about the OS. :) – user541686 Jun 5 '11 at 23:18
  • No offense, but if the person did the ole pull the plug without using "safely removal" tool, it's not the fault of the OS being whatever it might be; Nix or Windows. – robx Jun 6 '11 at 3:12
  • The thing is i done this lots of times on linux, friends do that too and well on windows, it shouldn't have done any big damage, break the files last written perhaps, but not totally brick a partition. Oh and about antipathy to windows - chkdsk once removed perfectly good data on this drive insisting that a : in a filename must lead to its deletion on the spot (my fotos had hh:mm timestamps). This failure also could be provoked by windows internal mechanisms, because the drive contents shouldn't have been modified, and as such no data should be harmed by cutting the power at any time. – Krzysztof Bociurko Jun 6 '11 at 10:25
  • Of course, i know i did bad and i'm trying to repent here for the sake of my data :) – Krzysztof Bociurko Jun 6 '11 at 10:26

The unsafe removal of the drive was your downfall.

You're going to have to either run data recovery to get the files off, format the drive, and move everything back, or risk it with one of the Linux tools.

Also, there's nothing wrong with Windows 7. You performed an unsafe removal, so it's not Windows' fault.

  • Of course, I do realise it's my fault, just pluging off a disk that was used only to read didn't ever pose a real threat, not to mention total drive failure. Still, if i had any way to access the data this post would not be here - any tips on the data recovery part? – Krzysztof Bociurko Jun 5 '11 at 22:42
  • There are many free and for-pay Windows tools that can do the scan and recovery without damaging the drive. Have a look through this site under the data-recovery tag for ideas. I'm not familiar with the Linux environment, but I seem to recall their tools being a little more permanent. – user3463 Jun 5 '11 at 22:53
  • Currently trying to do it linux style, with software i dug up from the tag. Looks like i'll be needing a 1TB drive to put a dd of the disk to be really sure. – Krzysztof Bociurko Jun 5 '11 at 23:10
  • Still, why did it fail so miserably? The hardware looks kind of OK (first 12 gigs copied without any problem, the data there looks fine, been able to read some plaintext files) – Krzysztof Bociurko Jun 5 '11 at 23:11
  • The MFT wasn't cleanly written to, so it marked the drive as unreadable. This is quite normal with drives removed unsafely. – user3463 Jun 6 '11 at 3:55

Well... Before any tools are ran, I do recommend making an image... and if you don't have the hardware for a straight up dd image, try piping it into lzma, and compressing it as far as you can:

dd if=/dev/sdb bs=512k |lzma -7 -c - >ntfs.img.lzma

You can substitute sdb for anything... sry if that sounds condescending, it was unintentional. Judging by your post, you know the gist of dd. If you're impatient like me, you should pipe it into pv and get a progress bar:

dd if=/dev/sdb bs=512k |pv |lzma -7 -c - >ntfs.img.lzma

I only put the compression level of lzma at 7 because 9 can take forever on a slower processor. Once that is out of the way, I recommend testdisk and it's sister application photorec. Testdisk is capable of filesystem repair to a certain extent... I haven't used it myself much, however I know some people that rave about it. Photorec is a last ditch effort to recover all of the individual files, it looks for known filetype logical data beginning and end points. However, even though it may be time consuming, you should try ntfsfix first. If it completely destroys anything, then just pull from your image:

unlzma -c ntfs.img.lzma |pv |dd of=/dev/sdb bs=512k

And, just a couple of quick thoughts on what went wrong, I say don't blame it on either OS, they both played an equal part in damaging it. It was dirty from the Windows os unclean pull, and in attempting the ntfs-3g write-capable mount it was just further damaged to the point that windows no longer likes it. This is going to sound a little odd, but look in a kernel config, and ntfs write support is still labeled as experimental, and At-your-own-risk. As much as I hate Windows, I can't blame it this time around. Something odd with ntfs: unclean umount from windows is repairable from windows, unclean umount from linux is repairable from linux. Crossing the line with an unclean ntfs partition will usually kill it... sry, just one of those things.

  • Well, this could be the thing, hope it's repairable, through. From the time i used this NTFS on windows and linux it looks like both implementations are quite good, but a bit incompatible. Pretty sure tons of hard links didn't help either. And LZMA won't help much, maybe 20% or so, most of the data was compressed already, so it's not worth the delays. – Krzysztof Bociurko Jun 6 '11 at 10:36
  • Well, >_<... I'm sorry, I didn't know you had already thought about lzma... Still, there's good old testdisk suite, good luck! – darkdragn Jun 6 '11 at 16:45
  • Testdisk was able to rebuild mft, and boot sector... but everything failed the same afterwards, so i have to say - in this case, testdisk is worthless – Krzysztof Bociurko Jun 26 '11 at 16:08

The answer to this problem was restorer ultimate, apart from some big files (2GB+), logs and problems with some hardlinks (treated as duplicates) this fixed it.

Also the more i looked from the log the more it seemed that MFT was not the problem, not the root of MFT at least. Some stuff that was duplicated not binarly equal seems that the drive failed at shadow copy, and perhaps there were some loops or other really bad structure in the deeper part of MFT. Looking through logs it seems like all os implementations failed fatally, by that i mean segfaulting. An interesting log from 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):

BSD process name corresponding to current thread: mount_ntfs

And then it died.

So, looks i had a very infrequent problem caused by lazieness. For future reference: best fix is either doing what you should, ie unmounting the drive. Perhaps also disabling shadow copy on an external drive.

Anyway, restorer fixed it, and about the failure it looks like windows somehow contibuted leaving a partition in a state that a journaling system should not be in. Perhaps mounting it in linux also contributed, through i don't find it likely, ntfs3g doesn't fix stuff without asking, usually it isn't able to anyway or cries for user attention in syslog for that.

  • Side note: there was one thing i did not check before - trying to chkdsk after testdisk rebuild MFT (before that chkdsk died). The results: console full of error logs, all being fixed and all. And yes, after mounting the drive was free of errors! And data. Testdisk+chkdsk (and chkdsk alone) are a no-go. – Krzysztof Bociurko Jun 26 '11 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.