Hi Antonio,

Antonio Diaz Diaz wrote:

This leads to the following suggestion for a ddrescue enhancement to
handle platform/controller/driver specific values of errno after read

I think that mapping unknown Windows errors to EACCES, as Cygwin does, is wrong. Some of those unknown errors may be fatal and should make ddrescue quit.

Source code control forensics reveals that the EACCES(S) decision was done in last millenium. This related comment was added in August 2000 and persists until today: /* FIXME: what's so special about EACCESS? */:

The problem is that no errno is offered for "unspecified" errors and interestingly also not for "media changed". Here the current errno.h from the Cygwin CRT (aka "newlib", https://sourceware.org/newlib/):

A fallback is needed, see the windows error defines and Cygwin's mapping table:

Any suggestion for a better fallback errno?

For example, if Windows returns ERROR_MEDIA_CHANGED(1110) because the medium really was changed, it is wrong for ddrescue to ignore the error and continue reading the new device as if it were the old one.

Of course. But an actual media change situation should usually not occur in typical ddrescue use cases (experienced console user only, being very careful, exclusive access to physical machine, ...)

Therefore I propose the following simpler change:

- If ddrescue quits because of a fatal error, print also the value of errno in the final message.

- Add the option '--continue-on-errno=<n>[,<n>]' for systems like Cygwin that map non-fatal errors to fatal errors. (Allow ignoring multiple errno values).

- Document that '-O, --reopen-on-error' may be needed when using '--continue-on-errno'.

Great, this would help.

For diagnostics of possible other "interesting" behavior, it would also be helpful to see an errno if interpreted as non-fatal but with unexpected value, e.g. different from EIO.

Best regards,

Reply via email to