> > > > > > > > > > > Domain mapfiles can be used for both purposes. You need a > separate tool to generate mapfiles containing the sectors accessible through > each head. Then, get the sector map of the desired files using another > utility (in mapfile format), and finally combine the mapfiles using the > ddrescuelog command. > > > > > > It would be probably best to automate this using some wrapper (with a GUI > or curses-based interface). It's definitely beyond the scope of ddrescue > itself. >
Thanks for the reply. As the recovery progressed it became apparent that the LBA to physical mapping is quite complex. I suspect the proprietary recovery tools use manufacturer specific (and undocumented) ata commands / serial port debug to extract this information from the drive). Do you happen to know of any recipes to extract filesystem block usage in mapfile format? I couldn't find anything existing, but don't want to re-invent a new utility. My thinking so far... ntfsclone allows a meta-data only clone of an NTFS volume into a sparse file. Assuming it can read the meta-data blocks, this sparse file should match the layout of the metadata blocks - although I'm not certain whether this includes any indirect blocks (zfs terminology?) or bitmaps locating all the user file data. (I'm no expert on the NTFS layout). The next step might be to write a utility which implements a data-source for ntfsclone which overlays the sparse image of metadata (so the clone utility "sees" the filesystem), whilst constructing an extent map of all reads made whilst making a full clone. This extent map could then be used to feed ddrescue. Peter _______________________________________________ Bug-ddrescue mailing list Bug-ddrescue@gnu.org https://lists.gnu.org/mailman/listinfo/bug-ddrescue