Originally posted by whomnet
aMule said it was corrupted a dozen of times!. I stopped the file, and so the good parts growth (those of the fresh downloads), with less corrupted parts found.
Hmm, could be aMule getting confused or a popular source offering
corrupt data.
With aMule still running I used DonkeyDoctor to check the stopped download's chunks, and it said everyting was OK.
Unfortunately, a run with aMule still caching data probably doesn't
mean much. BTW, is DonkeyDoctor reliable ? Does it use the same
code as some other incarnation of eDonkey ?
At the first check the program detected that the downloaded part
marked as corrupt was OK, and so transferred the file to Incoming.
Hmm. Could be either DD missing the corruption, aMule halluzinating
there was some, or a good fairy fixing the file while aMule was writing
it to disk :-)
What's interesting is that this was reproducible. So it could mean that
aMule somehow corrupted data that would not be saved to disk, or
that it is using data that may be saved to disk in an incorrect way.
(Or, if the problem is in DonkeyDoctor, it may do the same.)
One thing I'd look out for is the use of ranges. I've seen that aMule
frequently describes byte ranges with a (start, end) pair, there "start"
is the position of the first byte, and "end" the one of the last byte.
It's quite common to use a similar pair, where "end" is one byte
beyond the last byte, so length = end-start, and a loop
for (p = data+start; p != data+end; p++) will traverse the whole range.
A mixup of that kind could explain why aMule sometimes seems to
get lost. (Of course, it's probably something else. It's never the bugs
that seem logical and plausible :-)
- Werner
