Re: [core-dev] VerifyingFile returns false positivies whencheckingfor file corruptions

It would have been good to extract the signgificant part of your log, which 
contains repetitions of this fragment:

49127 DEBUG [BlockingVF] downloader.VerifyingFile.verifyChunk - verifying 
interval 37748736-38273023
49147 DEBUG [BlockingVF] tigertree.HashTree.isCorrupt - interval 
37748736-38273023 verified false
49148 DEBUG [BlockingVF] tigertree.HashTree.isCorrupt - 
PMLCIGNME2ZK4OIRSVTSHVSFA6ZHXOM4FJKOYNQ
49149 DEBUG [BlockingVF] tigertree.HashTree.isCorrupt - 
N7TTY222JAL3C45GM3S4IL6Y5IYEWKK46Q44IDQ
49165 DEBUG [BlockingVF] tigertree.HashTree.isCorrupt - 
PMLCIGNME2ZK4OIRSVTSHVSFA6ZHXOM4FJKOYNQ
49166 DEBUG [BlockingVF] downloader.VerifyingFile.verifyChunk - block 
corrupt!
49190 DEBUG [BlockingVF] tigertree.HashTree.isCorrupt - interval 
37748736-38273023 verified false
49190 DEBUG [BlockingVF] tigertree.HashTree.isCorrupt - 
PMLCIGNME2ZK4OIRSVTSHVSFA6ZHXOM4FJKOYNQ
49191 DEBUG [BlockingVF] tigertree.HashTree.isCorrupt - 
N7TTY222JAL3C45GM3S4IL6Y5IYEWKK46Q44IDQ
49207 DEBUG [BlockingVF] tigertree.HashTree.isCorrupt - 
PMLCIGNME2ZK4OIRSVTSHVSFA6ZHXOM4FJKOYNQ
49208 DEBUG [BlockingVF] downloader.VerifyingFile.verifyChunk - recheck: 
true

But also to exhibit what you really did to recompute the hash to log the 
third hash value, which matches the expectation.

So your log demonstrates that VerifyingFile incorrectly computes the hash. 
But I don't understand why the filesystem has an impact here, notably when I 
see that this occurs repeatedly for the same file fragment (with the same 
expected hash value.)

My opinion is that VerifyingFile is not feeding the TigerTree hash with 
enough data, and there may exist a index variable used in a loop that has 
still not been assigned with the correct value before using it to compiute 
the hash. This case may exist in a special limit such as final step before 
exiting a loop.

If it was really filesystem-related, you would not see the same error 
repeatedly, because in fine, the file would be OK with all precent writes 
already committed to disk. So my opinion is that Verifying file is not 
always feeding the hash with the data that it has really commited to file...


----- Original Message ----- 
From: "Gregorio Roper" <[email protected]>
To: <[email protected]>
Sent: Tuesday, July 26, 2005 2:42 PM
Subject: Re: [core-dev] VerifyingFile returns false positivies 
whencheckingfor file corruptions


> This is probably my final contribution on that topic because I don't know
> nearly enough about disk I/O operations.
>
> What I can tell is that a problem seems - at least in part - to be caused 
> by
> RandomAccessFile. So far I've seen it twice in maybe 100 corrupt chunks 
> that
> the chunk would verify properly when reverifying again without any write
> calls to the RandomAccessFile in-between.
>
> Something else that strikes me as odd was that a chunk that repeatedly 
> failed
> to verify would always fail with the same wrong hash.
>
> If I had to make a guess, I'd say RandomAccessFile#write(byte[]) does not
> necessarily block until the whole write operation has finished on my
> computer, which may point to a SuSE Linux 9.3/ReiserFS issue.
>
> -- 
> mfg
> gregorio roper
>
> I have attached the log file of one of my sessions.
>
> Regarding the log entries from HashTree#isCorrupt:  the three hashes shown 
> are
> in this order: the hash of the data received from the VerifyingFile, the
> expected hash and a second attempt to calculate the hash of the data from 
> the
> VerifyingFile
>



> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev
> 

_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev