On 9/6/07, James W. Watts wrote: > Reading the image from the rescue drive that I DBAN'ed produced the same > results as before. Still > only showed a partial recovery. And the files it did show were unreadable. > > I guess the filesystem is damaged, as Antonio suggested. Is there any way to > repair it? > > James > > > James W. Watts wrote: > > # Rescue Logfile. Created by GNU ddrescue version 1.3 > > # pos size status > > 0x00000000 0x1321301C00 + > > The logfile says that ddrescue recovered 82161179648 bytes (82GB) > without errors. If you can't mount the image produced by ddrescue it > should be because the filesystem in the (aparently not) damaged drive is > corrupt. > > If the rescue drive is larger than the damaged drive the comparison is > going to fail, and the rescue drive will contain at the end whatever > data left there by earlier uses of the drive. Wiping the rescue drive > with DBAN will make a difference on the files recovered with Get Data > Back, but won't remedy other errors the filesystem may have. > > > Regards, > Antonio. >
You could download The Sleuthkit (http://www.sleuthkit.org) and try some of tools from there on the image. For example. I have a drive attached to a system via a Firewire hardware write-blocker. Example follows - img_stat - Display details of an image file mmstat - Display details about the media management system (partition tables) mmls - Display the layout of media management systems (partition tables) fsstat - Display details of a file system You can see how each command builds on the information provided by the previous one. [EMAIL PROTECTED] /TSK $ /TSK/sleuthkit/bin/img_stat -t /dev/sdc raw [EMAIL PROTECTED] /TSK $ /TSK/sleuthkit/bin/mmstat -i raw /dev/sdc dos [EMAIL PROTECTED] /TSK $ /TSK/sleuthkit/bin/mmls -i raw -t dos /dev/sdc DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: ----- 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000001 0000000062 0000000062 Unallocated 02: 00:00 0000000063 0361705406 0361705344 Win95 FAT32 (0x0C) 03: ----- 0361705407 0361882079 0000176673 Unallocated [EMAIL PROTECTED] /TSK $ /TSK/sleuthkit/bin/fsstat -o 63 -i raw -f fat32 "/dev/sdc" FILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT32 OEM Name: MSWIN4.1 Volume ID: 0xd6d6 Volume Label (Boot Sector): Lanex LLC Volume Label (Root Directory): File System Type Label: FAT32 Next Free Sector (FS Info): 215912422 Free Sector Count (FS Info): 4092157856 Sectors before file system: 63 File System Layout (in sectors) Total Range: 0 - 361705343 * Reserved: 0 - 31 ** Boot Sector: 0 ** FS Info Sector: 1 ** Backup Boot Sector: 6 * FAT 0: 32 - 88338 * FAT 1: 88339 - 176645 * Data Area: 176646 - 361705343 ** Cluster Area: 176646 - 361705317 *** Root Directory: 176646 - 176677 ** Non-clustered: 361705318 - 361705343 METADATA INFORMATION -------------------------------------------- Range: 2 - 5784459170 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 16384 Total Cluster Range: 2 - 11297772 FAT CONTENTS (in sectors) -------------------------------------------- 176646-176677 (32) -> EOF 176678-176709 (32) -> EOF 176710-176741 (32) -> EOF 176742-176773 (32) -> EOF ... lots of stuff I hit ctrl-c There are lots of other commands you can use. I wouldn't recommend the Autopsy front-end unless you find a way to stabilize your image a bit. Note the offsets from mmls if you get that far. I had a drive that was unmountable because the partition table was in a non-standard offset. I was able to hit it with the tools from the command-line, but Autopsy was not able to see it because it was not as configurable as the command-line tools it communicates with. -Jason _______________________________________________ Bug-ddrescue mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-ddrescue
