bug-ddrescue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestion about error control


From: Scott Dwyer
Subject: Re: Suggestion about error control
Date: Mon, 1 Jun 2020 20:37:30 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

The tools mentioned (hddsuperclone and DMDE) are not open source and have paid versions for a reason. The authors have spent much time and effort working on them to make them special. Realizing the different error conditions of a device cannot be done with normal commands. Comparing those tools to ddrescue is like comparing apples to oranges.

Regards,
Scott


On 6/1/2020 7:06 PM, Antonio Diaz Diaz wrote:
Hello kickman.

Thanks for your message and sorry for the late answer. I have been very busy.

anonymous wrote:
The two last can recognize and distinguish the error codes got from the
kernel after every read /write request. For example, when hddsuperclone
detects the disk is offline (not ready) - it just waits for it to become
ready again. So DMDE does. It shows different error codes allowing the
operator to make the right decision about what to do. But my favourite
tool ddrescue never made such a difference to the error codes! Either the
error code was "CRC error" or "Device not ready!"

I suppose those tools (hddsuperclone and DMDE) use non-portable ways to get those codes, because neither "CRC error" nor "Device not ready!" appear among the error codes returned by 'read'[1].

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html

Bypassing the kernel should not be done lightly on POSIX systems. As a portable program, ddrescue must limit itself to the error codes returned by 'read' as documented by POSIX. As a first approximation, 'EIO' may correspond to 'CRC error' and 'ENXIO' seems the best match for 'Device not ready'.

I'll implement some form of differential response to error codes in the next version of ddrescue. Maybe ddrescue could stop or ask the user when readblockp sets errno to EBADF, ESPIPE, or ENXIO, for example.

It may be also possible to implement a non-portable way to retrieve the drive status, and compile it conditionally with '--enable-non-posix'.

Feedback is welcome.

Best regards,
Antonio.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]