FM> If 2 files are 1 bit different you will *never* get the same
 FM> CRC. Or the same checksum either, using Niels' approach.

  You are offering Niels false hope. You can't talk bits when he is
adding up bytes.

 FM> If 2 files are 1 bit different you will *never* get the same
 FM> CRC. Or the same checksum either, using Niels' approach. The
 FM> likelihood of getting the same CRC for 2 files with *multiple*
 FM> bits different depends on the size of the file.

  As I said, I bow to your superior knowledge. I have never analysed
CRC (and I don't intend to).

 FM> There are, for example, 8,192 different possible 1k byte files
 FM> , every possible 32-bit CRC could have been generated from 256
 FM> of those files.

  I have lost confidence in you. I don't know the permutations of a
32-bit CRC (not having passed year-11 maths) so I can't check you,
but in year-10 I wasn't so busy masturbating and I know how to
calculate the permutations in a 1024-byte file (16,000 bits) and it is
as sure as wanking not 8192. Or even close. Or even within a million.
Or a billion. It's fucking heaps! And even if you are talking bytes, 
it's still fucking heaps.

  I suppose you are trying to explain Niels'approach to checksum (just 
add up the ascii) but even there you are miles out.

  To avoid large numbers, look at an 8-byte file of 2-bit bytes. Using
the Niels checksum there are 8*4 numbers and 2^16 possible files in the
16-bit string. That means 32 numbers serving 512 files and lots of false
files. If you make the files 64-bytes long you have 256 checksums 
serving 3 X 10^38 possible files. It's clear that the larger the file, 
the less satisfactory checksum is. The number of files is an exponential 
and the number of checksums is linear. I didn't bother explainign this
because Niels already knows it and so do I.

  Apparently, you don't. I have no idea where you got your 8192 and 256 
numbers from. I guess you were masturbating too much in year-9 and 
missed arithmetic as well as permutations in year-10.  

 BL> It's thousands of times more secure than checksum, and it's
 BL> fast because it's just bit-shifting.

 FM> It's certainly not faster than a checksum, if that's what
 FM> you're saying.

  That's not what I said (or am saying). I mean fast in the absolute
sense, as in not slow, quick, celeritous.

  By the time you have opened your file and read some it into a buffer
and then read the buffer character-by-character before reading more
until the end, the extra time spent CRCing each character is not
significant. In that way, it is accurate to say that CRC-32 is fast,
in an absolute sense.    

 FM> But I can CRC over 200meg in over 5,000 files at nearly
 FM> 40meg/minute. 

  How fast is it if you don't CRC? About the same, I would expect. I
was doing a CRC so fast that it didn't measurably slow blockreads.

 FM> I've done 3 in Pascal/BASM - the 32-bit used in PKZIP & ARJ,
 FM> the 16-bit used in the other archivers, and the 16-bit used in
 FM> XModem.

  I did a zmodem CRC-32 and began by expecting that it would slow the
process. In fact it didn't, not at all.

 BL> There's another on TML one named CRC_V3.LZH (34K) written by a
 BL> uni wanker who explains it in the finest detail.

 FM> Thanks, I'll grab all those.

  Uni wankers stick together like superglue at a poofter's picnic.

  I think Neils would prefer a foolprooof EXE he could bung in his
BAT file, but I don't trust my programming ability enough to give him
mine. I wonder how he stores his checksums?

Regards,
Bob
___ Blue Wave/QWK v2.12
@EOT:

---