Date: Tue, 4 Apr 1995 21:32:37 -0700 (PDT) From: Poul-Henning Kamp <phk@ref.tfs.com> To: nate@sneezy.sri.com Cc: rgrimes@gndrsh.aac.dev.com, julian@tfs.com, freebsd-hackers@FreeBSD.org Subject: Re: new install(1) utility Message-ID: <199504050432.VAA06504@ref.tfs.com> In-Reply-To: <199504050426.WAA09399@trout.sri.MT.net> from "Nate Williams" at Apr 4, 95 10:26:47 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Using cksum is *not* the way to go, we already have Pouls benchmarks > > of cmp vs cksum on this, and cksum is not fail safe, it is possible > > for 2 files to have the same checksum but contain different data, > > very unlikely, but possible. > > I would have to see it to believe it. And, I don't remember any of > Poul's benchmarks that you are speaking of just that he said his > memmap/memcmp stuff for CTM was faster than cksums. Well, to make the cksums you will have to read both files, lock stock and barrel. The CRC based checksums >HAVE< a window for collision, a byte for byte compare doesn't. Doing the compare is easier than the cksum, (1..3 instructions per 4 byte versus <many> instructions). We have "install" in the vm-cache already, so exec'ing "cmp" will always take longer, plus the logic in the shell to look at the exit- code, plus people will invariably get it wrong in the Makefiles. QED: install is the place to do it, mmap+memcmp the way to do it. -- Poul-Henning Kamp <phk@login.dknet.dk> -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504050432.VAA06504>