Re: Suggestion about error control

[Scott Dwyer]

On 6/2/2020 4:34 PM, Antonio Diaz Diaz wrote:
> Scott Dwyer wrote:
> > The tools mentioned 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.
>
> Do you mean that I have not spent much time and effort working on 
> ddrescue to make it special?
No, you have spent much time on an excellent program, the only one of 
its kind in the open source world, and I bet with little financial return.
> > Realizing the different error conditions of a device cannot be done with
> > normal commands.
>
> IMO, non-standard commands should be used only when standard commands 
> don't suffice, because non-standard commands have a much higher 
> probability of causing a catastrophic data loss because of an 
> incompatibility.
>
> Ddrescue is a low-risk project. Maybe it won't maximize the 
> probability of recovering the data in difficult cases, but it won't 
> risk destroying your data by trying to be more clever than the kernel.
>
> It is good that there exist low- and high-risk projects. This allows 
> you to try the low-risk ddrescue first, and try the high-risk 
> non-standard software if ddrescue can't recover your data.
My intention was to reply to the suggestion of error control that 
ddrescue doesn't do like other programs. You must go deeper to 
accomplish this, at a minimum SCSI passthrough. I do it in Linux, and 
the other program can also do it in Windows I believe. Both are specific 
and non-portable, due to the nature of what needs to be done at a lower 
level. It is obviously more complicated, but when done correctly it is 
no more dangerous than what the kernel does. And FYI the kernel does NOT 
know best when it comes to a failing drive, it will thrash it more than 
needed in Linux, and Windows is even worse.
> > Comparing those tools to ddrescue is like comparing apples to oranges.
>
> Certainly. Ddrescue exposes its code so that everybody can see (and 
> improve) it. OTOH, we only have your word that the secret, 
> non-standard commands you use in your program won't eat the user's 
> data. :-)
Then maybe someone can come up with the SCSI passthrough code for 
ddrescue (hint to programmers out there that want to, I have produced 
open source Linux patches for this in the past that would be a good 
starting point, look into the old ddrutility stuff). I would actually 
like to see this implemented in ddrescue, and while I would not give 
away any of my secrets, I would be willing to at least point someone in 
the right direction if they were trying and had technical questions, 
although it would obviously not be my top priority to respond to those 
questions in a super timely manner. And yes, users of my software have 
only my word and no warranty ;)
> IMO every piece of software should either publish the full source code 
> (so that users can decide if they trust it) or offer an unlimited 
> warranty in case of misbehavior of the code.
If this were the case, then all software would be open source or open to 
incredible liability. Without the hope of financial gain (or having the 
fear of great loss), there would be much less effort, and many good 
programs would not exist. If you told me that my software had to be 
either open source or unlimited warranty, it would not exist.
> By the way, would you mind toning down the ads in your emails? This 
> mailing list is for improving GNU ddrescue, not for advertising other 
> software. Thanks.
Sorry, the only reason I mentioned the names is that it was in the 
original message. I try not to respond to the list, but sometimes I see 
something that I feel the need to respond to (sometimes against my 
better judgment). Maybe I should remove myself from the list so I don't 
see the emails, and therefore not tempted to reply. I might just do that...

Scott