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

--===============0286272308==
Content-Type: multipart/alternative; 
	boundary="----=_Part_5100_23791897.1123173210787"

------=_Part_5100_23791897.1123173210787
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Did you try the memmapped bytebuffer version I sent you some time ago? I ha=
d=20
a definite speed increase with it when doing LAN transfers, and it could=20
alleviate this problem. (It also had a definite VIRT memory size explosion)

Unfortunately that is way too experimental to include in the beta cycle at=
=20
this point.

On 7/26/05, Gregorio Roper <[email protected]> wrote:
>=20
> This is probably my final contribution on that topic because I don't know
> nearly enough about disk I/O operations.
>=20
> What I can tell is that a problem seems - at least in part - to be caused=
=20
> by
> RandomAccessFile. So far I've seen it twice in maybe 100 corrupt chunks=
=20
> that
> the chunk would verify properly when reverifying again without any write
> calls to the RandomAccessFile in-between.
>=20
> Something else that strikes me as odd was that a chunk that repeatedly=20
> failed
> to verify would always fail with the same wrong hash.
>=20
> 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.
>=20
> --
> mfg
> gregorio roper
>=20
> I have attached the log file of one of my sessions.
>=20
> Regarding the log entries from HashTree#isCorrupt: the three hashes shown=
=20
> 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=
=20
> the
> VerifyingFile
>=20
>=20
> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev
>=20
>=20
>=20
>

------=_Part_5100_23791897.1123173210787
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Did you try the memmapped bytebuffer version I sent you some time
ago?&nbsp; I had a definite speed increase with it when doing LAN
transfers, and it could alleviate this problem.&nbsp; (It also had a
definite VIRT memory size explosion)<br>
<br>
Unfortunately that is way too experimental to include in the beta cycle at =
this point.<br><br><div><span class=3D"gmail_quote">On 7/26/05, <b class=3D=
"gmail_sendername">Gregorio Roper</b> &lt;<a href=3D"mailto:[email protected]=
">
[email protected]</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" styl=
e=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; =
padding-left: 1ex;">This is probably my final contribution on that topic be=
cause I don't know
<br>nearly enough about disk I/O operations.<br><br>What I can tell is that=
 a problem seems - at least in part - to be caused by<br>RandomAccessFile. =
So far I've seen it twice in maybe 100 corrupt chunks that<br>the chunk wou=
ld verify properly when reverifying again without any write
<br>calls to the RandomAccessFile in-between.<br><br>Something else that st=
rikes me as odd was that a chunk that repeatedly failed<br>to verify would =
always fail with the same wrong hash.<br><br>If I had to make a guess, I'd =
say RandomAccessFile#write(byte[]) does not
<br>necessarily block until the whole write operation has finished on my<br=
>computer, which may point to a SuSE Linux 9.3/ReiserFS issue.<br><br>--<br=
>mfg<br>gregorio roper<br><br>I have attached the log file of one of my ses=
sions.
<br><br>Regarding the log entries from HashTree#isCorrupt:&nbsp;&nbsp;the t=
hree hashes shown are<br>in this order: the hash of the data received from =
the VerifyingFile, the<br>expected hash and a second attempt to calculate t=
he hash of the data from the
<br>VerifyingFile<br><br><br>______________________________________________=
_<br>core-dev mailing list<br><a href=3D"mailto:[email protected]=
">[email protected]</a><br><a href=3D"http://www.limewire.org/mai=
lman/listinfo/core-dev">
http://www.limewire.org/mailman/listinfo/core-dev</a><br><br><br><br></bloc=
kquote></div><br>

------=_Part_5100_23791897.1123173210787--

--===============0286272308==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0286272308==--