Daniel Shapiro <[EMAIL PROTECTED]> schreibt am 12.11.2007 7:43 Uhr: > It's stopped right now at 42074 and it says current > rate: 6755 kB/s and average rate: 7012 kB/s and it says "Copying data" > at the bottom but I don't think it is because the rescued # isn't > increasing. It says 0 errors and 0 errsize. I also tried to do ctrl+c > to interrupt it but it doesn't appear to be responding to that.
I think Daniel has a point there. Using ddrescue on several occasions I noticed that more often than not a damaged drive would just stall the reading process for hours (maybe forever) instead of returning an error. ddrescue sometimes updates display about every 30 seconds, giving also the opportunity to abort with ctrl-c. Most of the times however ddrescue will be as unresponsive as the drive and the only way out is to force an error by removing the device. Maybe this quite common real-world scenario could be addressed in ddrescue by introducing an option to set a reasonable read-timeout. Also checking the user-interface more often during wait-time for a read would be nice (for allowing ctrl-c and may be also giving some status-feedback). Allowing to abort in the middle of a read could be possible, when giving the user a choice whether the currently unfinished chunk should be finished, marked as an error or treated as being unprocessed. Of course there are a lot of other problems associated with this: What should ddrescue do when the timeout is reached, except to obviously treat it as an error? Will it be able to abort the read-operation on the drive and move on to the next (possibly also stalling) chunk, or will the drive just remain unresponsive still trying to deliver the last chunk? Can ddrescue know the difference? Can ddrescue reset the device to allow further operations? Will all this be consistent between platforms? Does the behavior change in direct- or raw-modes? While I am just a humble user of ddrescue, I hope Antonio will know the answers to most, if not all these questions. Greetings, Florian _______________________________________________ Bug-ddrescue mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-ddrescue
