As have I when there's a clicking... but this doesn't apply in this case. And that's only worked twice in about 50 tries :-( On Apr 13, 2010, at 10:47 AM, don wrote: > 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 > > _______________________________________________ > 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/278b9282/attachment.htm