Re: [Bug-ddrescue] Change of pattern after interrupt

[Antonio Diaz Diaz]

David Morrison wrote:
> I used 1.16 and all I did was to stop ddrescue and shut down, then
> restart the computer and issue the same command.
> [...]
> Now when I restarted it, it thought it had already done the whole disk
> and finished immediately. So I edited the log file to remove the bit
> after 274GB. I did not think to alter the status line at the top.

I think that your editing of the logfile explains what happened. 
Ddrescue was trimming when you stopped it. Then it began reading 
non-tried blocks after you edited the logfile and restarted ddrescue.

BTW, given the amount of errors in the drive, I recommend you to update 
to ddrescue 1.19 or newer. The splitting of errors made by 1.16 is 
slower than the scraping made by 1.19 and newer.

As the bad sectors in the logfile are not real, but caused by the 
disconnection, I also recommend you to change them to non-trimmed by 
restarting ddrescue with the option --retrim. (Use --retrim just the 
first time. Do not use it again if you restart ddrescue more times).


> Could I make a suggestion which would help to diagnose things like this.
> It would be useful if ddrescue kept an event log to record significant
> events. This would include start and stop times together with position
> and status. It could also include things like when it changes mode, eg,
> from non-tried to trimming. And the time stamps would be useful in
> tracking how long each phase took.

The option --log-rates already does some of the things you want. But I 
could implement a new logger for significant events and make it append 
to a file instead of overwriting it as --log-rates does. This would 
register a complete history of events of a given rescue (except edits 
made to the mapfile by the user, of course).


> This could be a separate file or inserted as comments in the existing
> log file like this:

I think a separate file is better because it may become large, the 
logfile (now mapfile) is periodically written to disk, and the mapfile 
can't retain comments from previous runs.


Best regards,
Antonio.