<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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...<div><div><br></div><div>I have the image made ...</div><div><div><i>[root@server /mount/archive/da-harddrive]# ls -la</i></div><div><i>total 78188872</i></div><div><i>-rw-r--r-- 1 ryan wheel 80026361856 Apr 13 03:46 80gb.drive</i></div><div><i>-rw-r--r-- 1 ryan wheel 425 Apr 13 03:46 80gb.log</i></div><div><br></div></div><div>When I try to mount that with mount_ntfs I get the following (expected) error:</div><div><div><i>mount_ntfs: /mount/archive/da-harddrive/80gb.drive: Block device required</i></div><div><br></div><div>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:</div><div><div><i>[root@server /mount/archive/da-harddrive]# ntfs-3g /dev/da0 /mount/drive1</i></div><div><i>NTFS signature is missing.</i></div><div><i>Failed to mount '/dev/da0': Invalid argument</i></div><div><i>The device '/dev/da0' doesn't seem to have a valid NTFS.</i></div><div><i>Maybe the wrong device is used? Or the whole disk instead of a</i></div><div><i>partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?</i></div><div><br></div><div>I'm still planning on testing out TestDisk.</div></div><div><br></div></div><div><div><div><div>On Apr 13, 2010, at 10:20 AM, Justin Kremer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Just a couple comments from a couple similar experiences I had...<br>The first is to figure out the mode of failure of the drive.<br>Is it from a laptop that was dropped during use? Is it a drive that<br>is having sectors go bad? Did someone do something silly and start<br>writing zeros to the wrong device? (not that I've ever done that...)<br>Different modes of failure may require different tactics, and can also<br>have very different results.<br><br>On Tue, Apr 13, 2010 at 9:49 AM, Ryan Coleman <<a href="mailto:ryanjcole@me.com">ryanjcole@me.com</a>> wrote:<br><blockquote type="cite">I was given leads to using ddrescue and dd but frankly that is outside of my<br></blockquote><blockquote type="cite">realm of knowledge and 9 of the 10 NTFS partitions that refused to mount in<br></blockquote><blockquote type="cite">Windows have mounted so far in FreeBSD (I'm running 8.0).<br></blockquote><br>ddrescue might be VERY useful in this situation. If you're not<br>familiar, it is basically dd, but it is forced to keep reading (and<br>writing) on when it encounters bad blocks. Some of the files will end<br>up corrupt in the disk image you create, but if you are fortunate, the<br>lion's share will be there.<br>You just want to start with the failed drive readable to you, and with<br>a location you can write the output file to with more space available<br>than the size of the partition you are trying to recover.<br>Both dd and ddrescue use similar syntax. As I recall there is a<br>slight difference, but starting with the basics, you should be able to<br>figure out the rest...<br>I think the command I used was: dd if=(path of the device name for the<br>partition to be recovered) of=(path of the file name to create from<br>the partition)<br>Certain other flags may be necessary, and ddrescue may be the<br>preferable command. The less times you have to try the better. If<br>the drive's condition is getting worse with use, you want to use it<br>less if possible!<br>I would expect it to take a LONG time.<br>Once the process is complete, you can try to mount the output file as<br>a loopback filesystem. (under Linux, I believe the flag is "-o loop")<br> If you're able to mount it, you should be able to copy any important<br>files off of it and then weed out what is intact and what is corrupt<br>without dealing with i/o errors in the middle of trying to copy a<br>batch of files.<br><br><blockquote type="cite">The drive is presently connected via USB on a SATA sled.<br></blockquote><blockquote type="cite">I know that there's something to be had on there somewhere:<br></blockquote><br>Personally, I would try to use the most direct connection possible.<br>SATA direct to the motherboard first. Maybe it's just my dislike for<br>middlemen...<br>- Justin<br><br>_______________________________________________<br>TCLUG Mailing List - Minneapolis/St. Paul, Minnesota<br><a href="mailto:tclug-list@mn-linux.org">tclug-list@mn-linux.org</a><br>http://mailman.mn-linux.org/mailman/listinfo/tclug-list<br></div></blockquote></div><br></div></div></div></body></html>