[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-ddrescue] various issues with ddrescue and probably ntfs and cygwin
From: |
Lance Colton |
Subject: |
[Bug-ddrescue] various issues with ddrescue and probably ntfs and cygwin |
Date: |
Wed, 18 Mar 2009 11:32:23 -0600 |
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] various issues with ddrescue and probably ntfs and cygwin,
Lance Colton <=