[EMAIL PROTECTED] (Larry Jones) writes:
> No. Any checksum algorithm can think that the file hasn't changed when
> it really has. (Timestamps can do the same thing, but only if someone
> has deliberately set the timestamp backwards [or the filesystem is
> broken]).
Or a tiny file modification happens fairly quickly -- remember most
UNIX platforms at least only track file modification with one-second
granularity. (Think "cvs upd foo ; echo blah >> foo".) Should CVS
insert a delay in its operation after updating a file (or set of
files), to make sure the timestamp on the file and in CVS/Entries is
no longer "current" before the user gets control back?
Or, a user could be in the process of modifying a file at the same
time CVS is updating it. (Shouldn't happen, but we all make
mistakes.) Should CVS read the timestamp of its updated file and then
re-read it to verify that the data in the file is what CVS just wrote,
and invalidate the timestamp otherwise?
Sure, the odds of slipping in a change within the necessary windows to
confuse CVS are low, but probably a lot higher than 2**-128.
It does not require deliberate action to confuse CVS in these ways,
just poor timing.
Now, you may consider one-second granularity to be "broken", but it's
the reality for a large number of platforms.
Ken
