On 22-Jan-2004 Ian Freislich wrote: > wrote: >> Ian Freislich <if_at_hetzner.co.za> writes: >> > Hmmm, very interesting. rm /home/ncvs/src/crypto/openssh/channels.c,v >> > and re-cvsupping and then updating this file fixed that. Wierd, I >> > would have thought cvsup would have noticed a corrupted file and >> > transferred the whole file. >> >> it might not if you use the -s option. if you do, you might want to >> run cvsup without -s once in a while just to be sure. I generally run >> cvsup without -s every night, and with -s every hour the rest of the >> day. > > I do run cvsup without -s: 'cvsup -L2 /root/supfile-cvs' This ought to be a FAQ. Problems like this happen when you have had filesystem corruption on the client machine. CVSup can't detect that kind of corruption. At the time it compared MD5 checksums, the data was still in OS buffers and it was still intact, so the checksums compared correctly. All of the metadata such as the timestamps and the file size are correct, so it has no reason to believe subsequently that there is a need to update the file. In literally 100% of cases when this sort of thing has been reported and people have saved the bad files rather than deleting them and re-updating, they have found that the corruption took one of two forms: 1. A single-bit error somewhere in the file. This was no doubt caused by a parity error. 2. Total garbage in one or more perfectly-aligned blocks of 8k bytes (or maybe sometimes 4K bytes). This is filesystem or VM system corruption. I bet I have analyzed two dozen cases like this over the past 8 years. The second category is a lot rarer now than it was in the days of FreeBSD 2.x and (especially) 3.x. You _will_ see the first category unless your system has ECC RAM in it. JohnReceived on Thu Jan 22 2004 - 18:23:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:39 UTC