Thanks for your post.

By all accounts, I have to politely deny that derivation. All in all, I am asking a straightforward question in regards to one or another thing - you confirm this with saying, that it seems to be "slightly" different. By using "slightly" different variations I am exploring my options of receiving a reply, basically desperately adding extra input to the context - so that it gives the idea to the reader of the things I have explored and, at least, am somewhat familiar with. I think by having this info - it is easier to guide a person, as you don't have to always start from zero: obviously that adds a layer of frustration. Now, as of again, I can point to the PIO mode as an example: even though I am using 3 question marks (those "parts" as you say) - the point of the question / matter does not change. The only thing I am asking is how do you put the drive into PIO mode - this, by all fairness, can be considered a single question. It does not matter whether I get the answer to the "parts", as they are only "byproducts" of the main question (which, still, sadly hasn't even been touched). The outcome for the most part of this, however, seems to result in blurred generalizations about quantity and time overhead.

With respect, the logic behind your statement about using gddrescue just because we should blatantly believe everything we read in the description - escapes me. The advise of using something, if its claimed benefits can not be assessed, seems a bit questionable. I find it sensible to evaluate applications on their declared purpose first and and it hasn't really been the case of living up to its expectations with gddrescue, thus far. That is why we are having this discussion. Also, where from did you get the idea that I was distancing myself from gddrescue due to its "range of options"? Honestly, the "range of options" in gddrescue is on par with dd - the latter has a nifty amount of flags that, in a sense, equalizes them. So I don't see how one is that more complicated than the other. It took a little bit more trial and error with gddrescue before I got the hang of it - however, the end result was flawed (or should I say useless) to all of my recovery cases (as it attempted to re-read the troubled area on a 2nd pass++, thus causing significantly longer execution time than its counterpart).

Now, regarding your example based on the author claims in the MAN. Honestly, it seems a bit inconclusive or slightly unconvincing (and that is the reason I started this dd vs gddrescue discussion in the first place). The most important thing to note here, which is kind of downed (skipped), is that none of the utilities would recover any more data than the other - if the block size was the same, right? Both of them would stall on the same defected sectors. In fact, gddrescue might've even recovered less on the 1st pass, if it considers a bad practice to wait for a sector with high response time (as stated in the MAN).

I assume, that the reasoning behind "whereas ddrescue would start to skip ahead after the first error and reach the later, readable, part of the disk much more quickly" is based purely on the block size. By default, dd operates in blocks (1x sector of 512B) and gddrescue operates in clusters (essentially the same thing, but 128x sectors, instead). So, the only reason why the latter might've performed better (faster) in this case - is simply skipping ahead, without probing if there is any recoverable data left behind in the disregarded sectors. Sure, it will attempt a 2nd pass - but will the drive survive until the 2nd pass? This is all very relative and mostly based on that artificial constraint of the drive obligatory failing within a short timeframe. The big question is, does this adequately reflect reality? All of the logical recovery cases that I have come across - the drive never perm-died like that (there were a couple of Seagates that slightly mimicked this [different] situation, but a large cluster didn't help them [as it triggered the same fault anyway] and once the power was cut and system started - they came back alive). I can accept the fact, that the author is referencing a real-life situation, but I ask you - is this the often occurring case in your line of work? My humble experience tells me, that this is a minority instance. The majority of the cases is probably related to having bad sectors randomly scattered over the drive (again, I am assuming, because that's what I have witnessed multiple times) and that the drive isn't going to visit its deathbed in an hour. So, gddrescue will be more successful in the case when we have a large amount of linear UNCs and when the drive is really going to die after an X-th hour - but the probability of this occurring is much lower. It is only the default cluster size that could help gddrescue here to recover more data. And with the same block/cluster size - they will perform identically.

One more thing I'd like to address. When I'm speaking about the "majority" of the cases - I am mostly implying the standard usefulness. Like, which tool would better suit a situation that occurs the most. To me, it seems that dd can do almost everything here. Yes, it lacks logging and it doesn't have an ability to perform multiple passes due to that or reverse operations. But do you need these features in the majority of the cases? gddrescue will blast through the drive with a large cluster, but it will also recover less data, which will wreck and corrupt a lot of files on the filesystem. Yes, we can say that this is only on 1st pass. But, on the 2nd pass we will have the same timeout delay occurring as we did when going through the 1st pass! If I want to maximize the amount of recovered data and I want to spend as little time as possible on a disk with an average damage of, lets say < 1000 sectors, how is gddrescue going to help? It won't. It will take me far longer, than if I used dd with minimum block size.

I have checked out various blogs and sites on gddrescue before this. Frankly, I've mostly found them copying over the claims in MAN or no reasoning behind using X instead of Y at all.

Anyway, I appreciate your time, Vulcan, thank you. Hopefully my skill will see improvement in the near future

I have already attempted data recovery in the past. As I said - all of them were logical (except for that recent WD drive with stuck heads). The Q&A is mostly based on that. So the validity of your statement speaks for itself (I have a hardware issue, while the Q&A is software related, so how is it going to be of much help in this situation?).

Does DR induce a habit of reading between the lines? I already stated, numerous times, that this drive was going to a DR tech. regardless and it has already left my premises on friday I will repeat again - the reason I am asking questions is because I have around 30 "broken" drives at my disposal. So, it would be a good idea to try some things out and possibly get into this niche, as well.

Though, I completely support your agenda on the importance of only qualified personnel dealing with valuable data (I am not attempting that on the disk in question, I will only attempt that on my graveyard of disks).

Unfortunately it seems to me that you have fundamentally not understood how ddrescue can be advantageous (depending on the specific disk fault & engineer skill in using ddrescue).

I can see that I've been wasting my time so far (thankfully I had predicted this possibility, and so didn't spend as long replying as I could have done - like to that PIO question ). So I'll leave this thread after addressing just one of the factually incorrect points in your posting, which therefore led to an incorrect strawman argument in your posting:


Wrong assumption. See ddrescue source file "rescuebook.cc" and see how the ddrescue first pass would react to unreadable sectors. There are other factually incorrect assumptions in your posting too, so I see you wasting lots of your time building decisions around incorrect assumptions, which is a shame.

Your experiences are obviously different to mine, and personally I find your arguments against ddrescue unconvincing (especially those based on incorrect assumptions) from my experience of using the tool, so we can agree to disagree about which tool we would use.

Good luck with getting the information that you seek, and perhaps other members will help you further - but I'll stop here on this occasion.

Unfortunately, it seems to me that you have a fundamentally flawed way of handling a discussion. Sorry, but I can't find any other way of saying this. Carrying out a logical conversation involves participation from the according parties on the matter in question. Here, I have a hard time finding any resemblance of that. Like if I am sending ICMP ECHO packets your way, but 75% of them get lost in transit. A failure of communication. From where I am standing - intentionally induced one by your side.

You are saying, that I have a misconception in the recognition of gddrescue's advantages. I am even surprised with the word "fundamental". Something fundamental should be well established and evident, so to say "layed out on the surface". If it's really fundamental, then it should be easily recognizable and therefore easily opposed. Are the presumed "advantages" of gddrescue really that recognizable here? No. Otherwise you would've easily opposed my point of view with objectivity - technical details, examples, facts. Where are they? I don't really see them. All I get is basically this: "You should use it because it's better because it's say so in the MAN and that's all I know, so take it for granted!". Rather questionable context, don't you think? What amuses me the most, is that you don't even bother providing a single comprehensive example that would prove me wrong. You just retaliate saying "Oh but there is something! I am just not going to tell you what!" - what is the point of this? Remember, when I couldn't even call this a discussion? How can you debate something without being able to back up your claims? Just saying that the other person is wrong, without any proof? What are you achieving with this? How am I ever going to find out the truth, if you can't even correct me in my statements? If, as you are saying, I am making decisions around factually incorrect asumptions - then tell me what and why! Otherwise, obviously, I will still retain my "false" observation. It's kinda ridiculous - you seek the truth about something only to find out, that the person presumably knowledgeable enough to provide it - might not know it himself. Really sucks when the moment you thought that you were going to learn something worthwhile - the other person abandons ship. What?

Now, you are pointing me to a source file, that presumably holds all the earth's secrets on gddrescue's superiority. I haven't "fundamentally" examined it, but I find it odd that you can't formulate your thesis on what's in there that's actually going to make gddrescue recover any more data than dd on 1st pass or if they both use the smallest block (cluster) size available - 512B. Even theoretically thinking, if gddrescue is based on dd and uses the same system calls - it will explicitly timeout on a UNC sector as long as dd. Whatever gddrescue does with block size changing algorithm (reverse-forward attempts with splitting) on a 2nd pass - is already irrelevant (a 2nd pass will cause extra delay when encountering the same troubled areas that were stumbled upon on the 1st pass - this negates the benefits of using a large block/cluster execution time wise).

I was trying to be polite, coherent and thorough. I didn't cry out with hundreds of exclamation marks and dozens of HELP HALP words. In return, I only got vague generalizations and mostly evasive, abstract replies. Most of the straightforward questions, where I expected at least some sort of a fitting answer (a pointer) - have been simply ignored. Overall, I have to say, that I barely gained anything from this. I don't know why do you have such weird helping strategy. Basically, deliberately creating an impression of saying something, while actually saying nothing. Yes, you were indeed wasting your time with the intent of wasting mine. Have you really delivered on any points that I have been asking? Crap, I would've been highly appreciative for even a single proper answer that is not offtopic! But this never happened. Instead, I got a senseless moan that just wildly exxagerated the quantity and therefore the amount of time needed to cover my questions. Posing to be a possible victim of time suckage and at the same time replying with many paragraphs about practically nothing (hello time waste?) is an interesting endeavour. Of course, we are all burdened by limitations in time, inspiration and will - but, if you are going to help someone, try to actually do it to some extent, instead of just pretending to do it. It really feels like the only person who has wasted his time by reading inconclusive input - is me.

Odd.

If I'm the only one who dislikes the approach of you asking hypothetical questions (and then arguing with replies based on experience), then you'll get plenty of help from others here. If that doesn't happen, then it might just be you who has been expecting too much.


That's because I didn't agree to a discussion. This is fundamentally a Q&A board, as you would know if you'd watched here for a while. I find it very inefficient and time-consuming to try to reply to a sceptic by email/forum, and I choose not to do that when I recognise it happening - as has happened in this thread. It's completely different face-to-face or on the phone, and lively discussions & debates are part of my daily engineering work.

I was attempting to answer some of the initial questions from you, despite there being too many and them being too vague for me to attempt them all. It's only when you argue with the answers I've given and I see you've changed this from Q&A into a debate / discussion, that I decide to bail out completely. I would not have replied at all. if you had said initially that you wanted to debate, and not the answers to those specific questions.


That's the whole point - if the advantages aren't obvious to you, even after reading the ddrescue docs, and since you argued with my earlier example (on a part in the manual which you quoted!) then I see there is little more that I can do. As I said before, I did not agree to try to convince a sceptic in this thread. You will always be able to say (and have said) "that example isn't realistic" or "most faults aren't like that", no matter how much I try to help, or how much I explain from my experiences about different types of disk fault.

Overall, I don't care if you use ddrescue - your decision makes no difference to me. Hence why I choose not to spend the time discussing it. For both our sakes, if you prefer to use dd instead of ddrescue then please, just do that.


I don't just say it's "in the MAN", but see above point - you'll always be able to claim that something hasn't been proved. You're also assuming that I want to "prove you wrong". I don't. I really don't care. If you don't like ddrescue then that's fine with me.

My previous example of ddrescue handling a disk with lots of errors at the start, where I saw a benefit of using ddrescue, was based on a real disk from a colleague's sister. He had already tried recovering data using dd for her, but the disk would start to click and recover nothing useful before disappearing from /dev, while sequentially reading that initial section. (The story is much longer, but I deliberately shortened it as the details are not relevant to the topic of dddrescue - but they are a great example of why people should not ask their local "PC shop" to do data recovery ).

He brought the disk into my lab. I then used ddrescue (and hdparm), multiple passes with different settings and recovered all photos but one from the clone (12kB unreadable out of 40GB on the original, no matter what I tried) before the disk then stopped reading anything at all (continuous clicking on power-on, probably hastened by what the "PC shop" had done) - all that recovery in less time than he had already spent recovering nothing with dd, the previous evening.

I thought it was a great example - it's based on actual experience, it highlights something about the ddrescue approach which is even explained in the ddrescue manual (in the part which you quoted!), and yet you claim I'm just repeating "take it for granted" and dismiss that example. And after you dismiss my example, you then expect me to spend more time on a discussion which I didn't agree to in the first place ?!

Odd.

(Yes, the irony of me spending time to explain why I don't want to spend further time on this discussion, is not lost on me )

Truly, for the most part, I am asking specific questions in need of specific answers. The dreaded PIO can serve as an example, again. How do I put the drive into PIO mode? - what is so hypothetical about this question? Makes me wonder why would anyone label it as such even though it has no relation. It might be lengthy in reply, yes, with variables and IF/ELSE clauses - but how is it hypothetical? The only thing I was expecting was an answer, that could've been in a form of a pointer or even something conclusive! All of my other questions retain the same undertone. The only thing that could potentially be considered hypothetical - is the gddrescue vs dd example. The point you are making now, however, is that the majority was "hypothetical" so you didn't bother to start with. I think we have already established, that I asked about 5-6 questions overall that needed an answer, while other "parts" could be disregarded, as they only served as pointers on my part. So it seems to me, that the argument about extensive quantity causing timing overhead is a bit overrated and therefore inappropriate (especially due to what I got in return). The problem is not the way I ask questions, it's that they remain unanswered (not even a scratch the surface stuff) and I am blamed for asking them

You are saying, that this is essentially a Q&A board - agreed, but this is also a forum. It is impossible to deal with every issue using the same approach. Some issues require feedback, comments and sharing of information (statements / opinions / arguments), in order to be able to successfully find the root of the problem along with a solution. And that, to me, seems to attain a lot of attributes of a discussion. I was making more of a figure of speech in this regard anyway. It doesn't matter what do we call it - it doesn't change the actual point. Which is, that you do not provide any sensible proof / details / facts to back up your claims when an answer dictates it. What good is an answer without it, when the whole purpose of asking one was to get clear evidence of X being superior to Y? How do you intend to prove a point like that? When I tell you this - you just facepalm and call me a skeptic. Yes, of course I am one in this regard! Because I am asking a question due to BEING SKEPTICAL in the first place. How else does it work? And obviously my skepticism will disappear when I am provided with proof!

So, let's not twist the facts here - I am not debating something just for the sake of it, the sole reason I asked about gddrescue vs dd was to get coherent evidence of one being better than the other. Was is ever provided? Instead, I suddenly become an overall skeptic out of nowhere, that started doubting everything along the way, as you say. The nature of this question was evident from the start, so you can't really blame me for turning it into something different. All in all, it's just semantics. So, it is beyond me, as to why would you randomly bring up this here - I guess, it is easier to color the conversation into something it's not and then just say that it's against ones personal values to contribute

It's really simple. Question requires proof - proof provided, evaluated = question closed. There's nothing more to it. I think it's a tad more fair to say, that you have set your mind to bail out earlier than the moment you have started answering anything

If you would've provided obvious proof - the advantages would've been obvious to me. That never happened. I have already said multiple times why the example you have provided was flawed - in one of my previous posts. It has nothing to do with "always try to doubt everything to an inappropriate level", but it has everything to do with being objective towards the fact of matter. The MAN itself creates a false impression of gddrescue being more efficient in data recovery than dd as a rule of thumb. Whereas in reality - it might only help in a fraction of isolated cases. What I have witnessed on various occasions only confirms that. As of again, I have described as to why have I come to this conclusion above, in my previous posts.

I dunno where from did you get the idea, that I am trying to make you care whether I use dd over gddrescue (but thanks for concern though!). Same goes for you wanting to prove me wrong. Huh? Here, actually, you are making a fundamental mistake - I'm not assuming that you want to prove me wrong, I WANT YOU TO PROVE ME WRONG. Because, that can only be done with providing proof! And then my problem is solved! I finally find out the mystery, as to why gddrescue is better / faster at handling UNCs than dd! See?!

I also noticed a small mismatch in your claims:



Notice, how you are saying, that this is only related to execution time.



Notice, how it is already related to the end result of recovering more data!



However, now you are claiming, that they are the same thing! Which they obviously ain't (there is a difference between recovering the same amount of data with different execution time and different amount of data with whatever execution time). And that I am purposely disregarding something that makes perfect sense. Which it obviously doesn't.
What you are essentially saying, is that dd could not recover any data, whilst gddrescue could.

This is wrong on all accounts. I have already assessed my concerns why I consider this inconclusive. But I will touch this topic again. But first, I would like to comment on your newly disclosed circumstances: even the purity of the experiment prevents it from being rightfully valid in order to establish the advantages of gddrescue. Why? Because, you did not make a run of dd over the troubled media on your system! Your colleague did it on another system! Not only there might've been a difference in the software base (different version of dd, different kernel - which can obviously give inconsistent results), but it is even unknown how your colleague attempted the recovery - what flags did he use for dd and whether he used the same block size as you (which is highly unlikely, as both of the applications have a tremendous difference in default block size). The latter things are very important. So, that speaks for itself.

Now, to the biggest mystery and the whole point of all of this:

Does gddrescue deal with UNCs any more efficiently than dd with the same block size, that would influence a difference in the execution time on 1st pass?. The most vital part that never got answered. This is the question. This is what establishes gddrescue's superiority over dd. So any proof presented should have been based on that.

Exactly as I expected, you claim my previous example of ddrescue usage was flawed, even though you don't know enough about the circumstances to make valid comments e.g. I do know which dd parameters my colleague tried the previous evening (I have them written on my notes here, from when he was standing to me, telling me the story!), and we used the same bootable live CD (his), hence same kernel, on the same system type (provided by our employer) - so yet again, your strawman arguments are incorrect.

However, finally, you make your position clear:


That might be your opinion, but I politely disagree with that definition of what "establishes ddrescue's superiority". For a program specifically designed to perform multiple passes (with different actions on each pass), limiting your definition of superiority to what happens on one pass, seems rather ... odd.

Exactly as I expected, you are still slightly shuffling the facts in order to shift the area of attention and claim both of your given examples as the same thing So it looks as if the only assessment I ever did - was based on the purity of the experiment, which discredits the validity of my comments from the very beginning This is false, as we are disregarding the difference between your initial example being flawed (a) and a structurally different one given at a later time (b).

I have already clearly differentiated between both of your provided examples in my previous post. They both have different context. So, now we just forget about that?



a) Here you are saying, that gddrescue wins in terms of execution time! Note, your statement says there is no difference in the amount of recovered data. That means, they recover the same amount of data, but gddrescue can do it faster, by your words.

Now, let's remember what kind of a question was I asking: why is gddrescue perceived to be superior to dd within the same working conditions? Let's define what means "superior" in this context: execution time wise and higher data recovery. Let's define what means "same working conditions": the block / cluster size used is the same, as well as the activation of the common flags that they share - this equalizes their working conditions to an acceptable level.

So, how can gddrescue beat dd in this case? The only way it could possibly win the race for the execution time, if the block / cluster size is the same, is to have some advantageous way of handling UNCs on encounter, that would make it spend less time on the delay caused by the kernel timeout on I/O errors. The MAN page makes us believe that there is some supreme algo, that does just that! And this is exactly what I was asking about! However, this claim seems to be false.

As I've already said earlier - I have tried logical recovery with dd and gddrescue around 6-8 times dealing with heaps of UNCs and in all of those cases the end result was the same in relation to the execution time. So, this certainly confirms and gives validity to the statement above (of course, not a clear 100%). Let's pinpoint one very important thing again - this is in the case of the block / cluster size being the same!

Here's how I replied to your initial example:



I think, taking that into consideration, by all fairness, your example can be considered flawed.



b) Here, however, you are already saying, that it wins in terms of the amount of recovered data! So compare a) and b) - two opposite statements. This is called an inconsistency and confirms the existence of 2 variations of your example. Also, how can gddrescue recover any more data than dd?! By definition (same constraints apply with equal working conditions) - only if it has a special algo. that can somehow access the defected sectors in a way that dd can't! It's like if dd was missing a direct flag and gddrescue had it. However, there appears to be no such thing, as the results of my testing have shown. Both of them access the troubled areas the exact same way - this is even further confirmed by the fact, that gddrescue is based on dd. So, the actual conclusion that I can draw from the presented example, is that you simply had a difference in the gddrescue's cluster size! Which makes perfect sense - as it's 1 sector vs 128. The most obvious suspicion here, is that your colleague simply did not wait for dd to finish with a smaller block size, whereas gddrescue was able to skip to the "good area" faster due to enjoying a significantly bigger cluster. So, this comparison is unfair and therefore flawed. However, there is still a possibility of your example attaining validity - but that is only, once again, if the block / cluster size was the same! So, was it?



I have explained in detail why I consider this to be irrelevant to the fact of matter. That's exactly what establishes ones superiority in this case due to the initial formulation of the question. It does not matter if gddrescue can change / adapt the cluster size on a 2nd pass, partially because that will cause additional delay when going over the bad sectors on a 2nd pass - which in turn will negate it's benefits and increase execution time dramatically. But more importantly, as the common belief (spread by MAN) is that it has some special algos, that can prevent it from timing out as much as dd when encountering a BB or that it can recover more data due to being able to access a single bad sector in a different way. As a sum up of everything - neither of these seem to hold true.

"non c'e' peggior sordo di chi non vuol sentire" = there's no worse deaf than who doesn't want to hear .

All this free stuff can do almost NOTHING when the problem exceed what free stuff can do, regardless of "algos" and "strategies".
If you really want to deal with certain kind of errors, there is no alternative to specialized equipment AND / OR knowing specific internals of YOUR disk in order to do some "magic".
Otherwise, you have to figure out how the "free stuff" act on your situation , trial and error.

Some people in this forum know the story of a declared "almost unrecoverable" disk that came in my hands and had a blended heads / shock / servo problem and where data was recovered FROM THE DISK USING ITS OWN HEADS and without using dedicated equipment, only working...... with the disk itself (sorry, magic is magic.... BLACK Magic !). 100% of necessary data was recovered, only some areas (unimportant) where servo was compromised were not cloned. I did not try the "blackest" magic on these areas as there was no important data on it, but I'm quite sure something "readable" was even there.
What's worst : on this disk , the people who had it previously , tried all the free stuff they could find on the internet (ddrescue, gdd... etc.) and all the attempts ended badly, skyrocketing reallocated sectors and at last rendering the drive almost inoperative...

@XXL:

Again, many incorrect statements and assumptions in your posting about the differences between GNU ddrescue & dd, and about the algorithms used by GNU ddrescue (these can be seen in its source code, and you could use that source to answer your own questions and see your incorrect assumptions) - but I won't reply further, as I've spent enough of my time on this.

If that makes you feel that you've somehow "won", then I have no problem with you thinking that

@BlackST:
Agreed - there are very real limits about what any free "standard" tool like ddrescue (or dd, or dd_rescue etc.) can do, and there are risks with using any of them.


I've been trying to say that, and to explain why hypothetical questions can't get detailed answers because "it all depends on that specific drive's behaviour..." but I've spent enough time on this thread.

I'm sorry I don't boast through forum threads posting hit-or-miss quotes with the intention of complimenting my ego Also, not a big fan of Harrold Potter So I'm not really into all that PG13 "wizardy-magic" stuffxx, but it's totally cool if you are!

What amuses me the most, is how deeply passionate you are at hating everything that has been giving people "a choise" throughout decades of years and has always radically pushed evolution. In your "perfect" world - one company has the patents to basically everything and noone can invent a thing without paying ridiculous royalties, so they give up before even starting. Of course, in that "world view", you are right on top of the pedestal or really close to it. I'm not going to comment any further - but I have acquired this observation from many threads you've posted to. I think it's pointless to talk about Unix and the philosophy that surrounds it, as one of the greatest examples of shaping our world - my suspicion is that you secretly dream of dropping nukes on those initial source codes or building a fence throughout the world and hold people at gunpoint, so that they wouldn't even get a slightest idea of this kind.

I'm pretty sure that whatever point you were making with your post - it only came off as a good performance at a vanity fair with decent self-advertisement. The only thing you constantly reference there, is how you beat the other poor folk. Totally relevant to the matters discussed in this thread! However, the very start of it actually does make some sense - but, surprisingly, no more than Cpt. Obvious.

Thanks!

Tbh, it sucks to see you come down to this level, Vulcan. I mean, could've had a proper conversation without all of useless irrelevant crap that came along with it. However, it wasn't me who set the pace and neither was it me who started to seed inconclusiveness and confusion. As I've said earlier, I think your "strategy" of helping people is a bit off.

"Incorrect" statements and assumptions that you never managed to address in a coherent non-questionable way. Otherwise, we would've had a clear understanding on the fact of matter. Talking about source code, without referencing any details of it in any parts of your replies as proof - really doesn't add much to the point you are making. It's like you're saying - "Something is there, it has to be there, but I'm not sure what is it, argh!"

It was never my intention to gain anything out of this but consistent information. This was purely about learning - nothing to do with "winning an argument". I still don't know why you'd even think it was ever about that.

Yes, it was.


Yes, it was - I pointed this out this confusion at the beginning.


I feel the same about your "strategy" of the way you ask questions.

But to bring this back on-topic...


Because you keep telling me (wrongly) how things work, and then expect me to explain how your incorrect explanations are wrong. If you had asked a simple question or two (not 14) and then stayed quiet and waited for a reply, things could have been different - instead you're constructing elaborate strawman arguments based on incorrect assumptions, and creating too many incorrect statements for me to explain them all within a reasonable time (as I said at the very beginning, where I warned you about the number of slightly different questions you were asking - and which you disagreed with). This is the result.


That's not what I'm saying - I know exactly what's there, as does anyone else with reasonable skills in C(++). It's not my fault if you don't understand the source code, and you don't clearly just say that and politely ask (and wait) for an explanation, without constructing further arguments . If I didn't understand some source code, I would remain polite and courteous (and not start being aggressive) towards someone whose assistance I needed to understand it.

In answer to that one point about the source code, I'll make one more contribution to the thread, to be helpful to other members and point out the basics (it's not quite this simple - but I'm not spending long on this reply). In the current ddrescue 1.15 source, in the rescuebook copy_non_tried() function, the skip_size variable doubles after a read error (notice the "skip_size *= 2" statement), to try to reach readable data quickly. That variable is reduced in size again, when data is later successfuly read. That behaviour only applies during that first phase of ddrescue (when non_tried blocks are read) or if the -T option is used when later phases have already started. If other members want more info, they're welcome to PM me.


Because you said I hadn't proved advantages of ddrescue to you (your choice of the word "prove"). That immediately sets an adversarial environment. Next time, perhaps you might want to choose your words differently, to set a different tone? Again, it's your choice. I choose to help people who ask polite questions, don't create elaborate strawman arguments based on incorrect assumptions, and don't argue aggressively with my replies. That's my choice.

It's you in need, not us. We're cool in our quasi-perfect world.