This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cksum giving inconsistent results on network drive

On Mon, Mar 21, 2016 at 5:09 PM, Nem W Schlecht  wrote:
> On Mon, Mar 21, 2016 at 3:49 PM, Erik Soderquist
>> I expect if you did a capture of the traffic, you'd find the traffic
>> itself has inconsistent data...
> If the traffic was bad, I'd suspect the byte count to be off as well,
> but if the byte count is consistent (which it is here), then the
> checksums should all be the same.

One random bit flipped in a stream of over 6.6M bits (not counting
overhead) would not change the byte count unless that bit happened to
be in the file description data rather than the file data
(statistically unlikely), but would affect the cksum results.  To
date, I've never seen the byte count off when I had network problems
corrupting files on SMB or NFS (outside of complete connection loss),
but I've certainly had corrupt reads and writes of the actual file

In the presented sampling, 6 out of 11 cksum results are consistent,
indicating that the average failure rate is slightly better than 1 in
10M bits.

> Have you tried a different hashing program, like md5sum or shasum, to
> see if you still get inconsistent results?

I would also be interested in these results, as it would focus or rule
out cksum as a potential culprit.  (Obviously from my previous post, I
have my suspicions already, but confirmation is still the best

I would also be interested in if you can do the same
cksum/md5sum/shasum on the server side and use some kind of semaphore
to trigger the check and get the results.

-- Erik

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]