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
errors:
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? */:
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/errno.cc;h=25dcf70#l113
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/errno.cc#l184
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/):
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/errno.h
A fallback is needed, see the windows error defines and Cygwin's mapping
table:
https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-headers/include/winerror.h
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/local_includes/errmap.h
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,
Christian