r-studio + ddrescue + map file

[thetoad]

It doesn't seem like r-studio can make use of ddrescue's map file. This could be useful for letting a user have confidence that data was recovered fully from a disc imaged with ddrescue.

ddrescue's map file would tell you if a block was read or not (if the all 0s in the file block on the file system are meant to be there or not). I think this would be a useful feature for you to add to the system (unless I was blind and didn't see that it was already there)

edit: other features that could be useful for r-studio if supporting ddrescue

generating a "fake" map file to enable ddrescue to focus on metadata blocks (i.e. directory entry) information vs actual data blocks (i.e. file content). i.e. if what I'm calling a metadata block is damaged, even if the content of the file is there, one won't be able to recover, by creating a "fake" map file, a user can focus on recovering those area (i.e by pretending the other areas are good). One would then want a utility to combine the original, the faked and the update of the fake into a new map file the is accurate to what was recovered

similarly, one could do the same for individual files, "I only want to recover the data for file X, generate me a map file that enables me to focus on that file" similarly, one can combine that in and generate a new map file.

edit 2: apparently someone asked about this a few years ago viewtopic.php?f=13&t=10829&p=16111&hili ... cue#p16111

I'm guessing as nothing has happened, its not really something that will happen

edit 3:

and actually I learned something new. one wouldn't have to create new map files that would then be "integrated", one could simply create what ddrescue calls a domain mapfile that marks all the data that one doesn't currently care about as "read" and marks everything that we want as unread. this doesn't overwrite the original map file which would continue to be used, but would enable one to have ddrescue focus on the blocks that matter at the moment.

I really feel this would be useful for people to recover data in a better way. r-studio provides the ntfs / fs knowhow in general, ddrescue provides the bit moving brawn.

[Alt]

It doesn't seem like r-studio can make use of ddrescue's map file.
I'm guessing as nothing has happened, its not really something that will happen

A little bit of patience. But no strict date promised.

[thetoad]

ah, you responded just when I was editing, see my last update. being able to output a domain mapfile from rstudio to target metadata (Say mft) or specific files, could be a massive win in consumer data recovery (at least for the technically incined)

while rstudio might be able to do all of what ddrescue can do, ddrescue has the main advantage that i can easily run it on a headless machine (i.e. just ssh in and image a disk)

[Alt]

while rstudio might be able to do all of what ddrescue can do, ddrescue has the main advantage that i can easily run it on a headless machine (i.e. just ssh in and image a disk)

R-Studio for Windows + RDP = a headless machine

[thetoad]

in my case, right now, I'm working on recovering a 10+ year old archive disk that seems to have had what I'd classify as "magnetic bit rot". i.e. if it seems physically fine (no clicking, 99.9% of the disk has been read, all but about 15MB), but 2.5MB of what isn't read is in the MFT (inode 0, per ddru_findbadntfs). And r-studio shows the same X's through the files/directories that are causing problems to be read, when I mount the "lossy" image I've already made

[thetoad]

while rstudio might be able to do all of what ddrescue can do, ddrescue has the main advantage that i can easily run it on a headless machine (i.e. just ssh in and image a disk)

R-Studio for Windows + RDP = a headless machine

yes (in a past life, I worked at MSFT on the RDP team), but in all honesty, its easier for me to run the rescue on my linux box which is meant to be up 24/7 and is in what is essentially my home server closet than my windows boxes which are in places where people sleep.

[thetoad]

as an example, a directory under the root was corrupted (512 bytes weren't read), and this seemed to prevent it from a) showing up in a mount and even r-studio wasn't enumerting it correctly. so while ddru_ntfsfindbad is far from perfect, it was able to help me identify the blocks that defined the directory. I then created a domain map to enable ddrescue to focus on that area, and it showed the 512byte block that it hadn't read, with the ability to focus on it, after about 10-20 read attempts, it was able to copy it into my image file and when mounted, the whole directory and its contents appeared and were able to be copied out.

the same can happen with r-studio today, even when one does a full scan (which can take a whole day on a large hard drive), if directories are corrupt, it wont be able to associate the files to the directory, by giving us the ability to say "these are the block I need so you don't have orphaned files", it would improve data recovery ability. This isn't as big a deal if files are all named uniquely. However, if you have directory after directory of files all named the same (say datasets where the directory is what made them unique) it can be difficult to untangle all the same named files and recovering the directory can be important.

[abolibibelot]

generating a "fake" map file to enable ddrescue to focus on metadata blocks (i.e. directory entry) information vs actual data blocks (i.e. file content). i.e. if what I'm calling a metadata block is damaged, even if the content of the file is there, one won't be able to recover

Not true, “raw” recovery is still possible in that situation, provided that the file was not fragmented.

similarly, one could do the same for individual files, "I only want to recover the data for file X, generate me a map file that enables me to focus on that file" similarly, one can combine that in and generate a new map file.

That would make sense only if NOT running a complete scan with R-Studio (since the whole purpose of doing such a “surgical” recovery would be to reduce the stress and strain to a minimum), so that would make sense only when the filesystem structures are not damaged at all, but another specific area is damaged. That would still make sense, but that would be a rather advanced feature, probably reserved for the most expensive version. (From what I've read, another cloning application can do something similar in combination with another recovery application -- but only with a “pro” license.)

being able to output a domain mapfile from rstudio to target metadata (Say mft) or specific files, could be a massive win in consumer data recovery (at least for the technically incined)

Targetting the $MFT with ddrescue : you can already do that with ddru_ntfsbitmap, part of ddr_utility (from the same author as HDDSC, although no longer supported this bunch of complimentary tools for ddrescue still works wonders).

but 2.5MB of what isn't read is in the MFT (inode 0, per ddru_findbadntfs)

Well, apparently you already know about ddr_utility...

[RForce]

There is a script to convert the ddrescue log to an MRT log posted here on the HDD Oracle forum. You can then use that map file in UFS Explorer so that when you save the files out, it will split the good and damaged files (based on the sector map) into separate folder paths.

[CKing123]

I have created ddr-mount that can mount ddrescue image files while passing I/O errors to bad sectors and any areas not yet read by ddrescue based on the map file. This creates a device (ddrm#, where # is a number) that you can load in any recovery software including r-studio, ufs explorer, and dmde. However, it is limited to Linux only so something like GDB does not work and ddr-mount also doesn't work on sector sizes that are not a multiple of 512.