openssh no longer compiles (as part of make world)

John Polstra jdp at polstra.com
Thu Jan 22 19:23:33 PST 2004


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.

John



More information about the freebsd-current mailing list