cksum giving inconsistent results on network drive
Mon Mar 21 21:27:00 GMT 2016
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
> 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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin