Sounds crazy but I had luck with sticking the drive in the freezer for 24 hours and then mounting it. -----Original Message----- From: tclug-list-bounces at mn-linux.org [mailto:tclug-list-bounces at mn-linux.org]On Behalf Of Ryan Coleman Sent: Tuesday, April 13, 2010 10:35 AM To: TCLUG Mailing List Subject: Re: [tclug-list] Mounting a bad NTFS partition I trust that it was not dropped - the device does not make any abnormal noises that would lead me to believe that is the case. It spins up normally... I have the image made ... [root at server /mount/archive/da-harddrive]# ls -la total 78188872 -rw-r--r-- 1 ryan wheel 80026361856 Apr 13 03:46 80gb.drive -rw-r--r-- 1 ryan wheel 425 Apr 13 03:46 80gb.log When I try to mount that with mount_ntfs I get the following (expected) error: mount_ntfs: /mount/archive/da-harddrive/80gb.drive: Block device required Is there a way to fake the Block device? I also tried just now to mount the physical partition with the fusefs NTFS port and got the following response: [root at server /mount/archive/da-harddrive]# ntfs-3g /dev/da0 /mount/drive1 NTFS signature is missing. Failed to mount '/dev/da0': Invalid argument The device '/dev/da0' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? I'm still planning on testing out TestDisk. On Apr 13, 2010, at 10:20 AM, Justin Kremer wrote: Just a couple comments from a couple similar experiences I had... The first is to figure out the mode of failure of the drive. Is it from a laptop that was dropped during use? Is it a drive that is having sectors go bad? Did someone do something silly and start writing zeros to the wrong device? (not that I've ever done that...) Different modes of failure may require different tactics, and can also have very different results. On Tue, Apr 13, 2010 at 9:49 AM, Ryan Coleman <ryanjcole at me.com> wrote: I was given leads to using ddrescue and dd but frankly that is outside of my realm of knowledge and 9 of the 10 NTFS partitions that refused to mount in Windows have mounted so far in FreeBSD (I'm running 8.0). ddrescue might be VERY useful in this situation. If you're not familiar, it is basically dd, but it is forced to keep reading (and writing) on when it encounters bad blocks. Some of the files will end up corrupt in the disk image you create, but if you are fortunate, the lion's share will be there. You just want to start with the failed drive readable to you, and with a location you can write the output file to with more space available than the size of the partition you are trying to recover. Both dd and ddrescue use similar syntax. As I recall there is a slight difference, but starting with the basics, you should be able to figure out the rest... I think the command I used was: dd if=(path of the device name for the partition to be recovered) of=(path of the file name to create from the partition) Certain other flags may be necessary, and ddrescue may be the preferable command. The less times you have to try the better. If the drive's condition is getting worse with use, you want to use it less if possible! I would expect it to take a LONG time. Once the process is complete, you can try to mount the output file as a loopback filesystem. (under Linux, I believe the flag is "-o loop") If you're able to mount it, you should be able to copy any important files off of it and then weed out what is intact and what is corrupt without dealing with i/o errors in the middle of trying to copy a batch of files. The drive is presently connected via USB on a SATA sled. I know that there's something to be had on there somewhere: Personally, I would try to use the most direct connection possible. SATA direct to the motherboard first. Maybe it's just my dislike for middlemen... - Justin _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota tclug-list at mn-linux.org http://mailman.mn-linux.org/mailman/listinfo/tclug-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20100413/51f8f949/attachment-0001.htm