Dear Larry,

Thanks for your mail, I feel a lot more comfortable
when I get good discussions like yours.  Much appreciated.

Larry Jones wrote:
> 
> The problem is the severity of being wrong.  If CVS thinks the file has
> changed when it really hasn't, the worst thing that can happen is you
> waste some time sending the file to the server when you don't really
> need to.  If CVS thinks that the file hasn't changed when it really
> has, the worst thing that can happen is that you lose changes.

And the 128-bit MD5 digest algorithm wouldn't catch BOTH of these?

>From the MD5 RFC:

  http://www.csl.sony.co.jp/cgi-bin/hyperrfc?rfc1321.txt

% It is conjectured that it is computationally infeasible to produce
% two messages having the same message digest, or to produce any
% message having a given prespecified target message digest.

You can be assured that using MD5, there is ZERO possibility CVS
could be fooled into thinking the file hadn't changed, if it
actually had.

Using timestamps relies on the assumption that file modification
is always associated with a timestamp change, and vice versa.
As we know, it's possible to have one without the other in both
cases.  That's what I'm trying to catch.

> Using timestamps can cause the first kind of error, but it can't
> (in theory) cause the second kind -- it is simply not possible to
> modify the file without updating the timestamp.

I disagree, both in theory and practice.  Used touch -r lately?

My point is that timestamps won't EVER catch this, whereas MD5
will catch file changes 100% of the time, regardless of
timestamps.  The only downside of using MD5 is the cost of pulling
every file into memory and doing the MD5.


> it is not only possible but necessary that many files
> have the same checksum (otherwise you'd have one really great
> compression method).

Compression methods are reversible:  You have to be able
to get out what you put in.  Digests such as MD5 have no such
requirement, so please don't compare the two.

Regards,

Mitch.
--
| mailto:[EMAIL PROTECTED]       | Not the official view of: |
| mailto:[EMAIL PROTECTED] | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |

Reply via email to