I know some of these problems aren't likely to be with the ddrescue code, but it would be nice to document them online since it's likely someone else will run into them eventually.
When running the generate-log mode, once it hit the sparse part of the image, the speed counter showed 0 even though it was processing about 500MB/s. When the input hard drive powered itself off, ddrescue marked the remaining 800GB or whatever as bad. This is probably by design, but there should be an easier way to fix this. I tried the option to retrim at this point (i think) and it started again from the end of the file. This isn't ideal as it caused other problems, see below. recovery onto a drive with 64K allocation units crapped out at around 150GB, getting errors saying permission denied whenever tried writing to it. same problem when writing into a virtual disk stored in a file on the same raid array using true crypt, problem occurred sooner, maybe at 130GB or so. i checked the error using process monitor when i wasn't using the truecrypt container and it shows 'file lock conflict', but couldn't figure out why, so i moved the output file to another partition and it continued normally. one weird thing i noticed is running chkdsk on the raid array after getting this error said that the disk type was "raw" and it wouldn't look at it further, even though the disk and data was working fine otherwise and restarting fixed it. i didn't try this enough times to verify this has anything to do with the file becoming locked, but it's worth noting for now. i don't know if it's because of the sparse files or compression i enabled, but once ddrescue started writing from the end of the file backwards the "size on disk" started growing way faster than it should, maybe by one gigabyte every few seconds even though it was only reading about 1MB/s. i discovered rebooting windows recovers this missing space. the log file got turned into a zero byte file for some reason when the disk space ran out, that should probably be fixed. anyways many of these problems could be avoided if ddrescue could split the image file into 100GB chunks or something, so i think that would be a good feature to add. i couldn't figure out how to convince windows to copy the images even though they compress or are sparse, it just tells me there's not enough space before even trying. i had to install an ftp server and fxp it to myself. _______________________________________________ Bug-ddrescue mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-ddrescue
