bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

modification date lossage


From: Aubrey Jaffer
Subject: modification date lossage
Date: Sat, 18 May 2002 11:31:46 -0400 (EDT)

"cvs update" (1.10.7) does not compare files with modification dates
older than the repository version.  This leads to two problems:

* If I restore a CVS-controlled file from an old zip or tarfile, then
  "cvs update" will fail to notice that it is not current.

This could be fixed by comparing "cksum"s of the repository and local
versions, rather than their modification dates -- perhaps too radical a
change.

A simpler fix would be to skip the comparison only when the modification
time of the file exactly matches its modification time stored in
CVS/Entries.

* If a CVS-controlled file is replaced by a symbolic link in a
  CVS-controlled directory, then the CVS client uses the creation date
  of the symbolic link rather than the modification date of the file
  which the symbolic link is pointing to.

  CVS thus fails to notice *any* change made after the symbolic link
  replaces the file.

Using stat() instead of lstat() would retrieve the modification time of
the actual file.

I found more than a dozen uses of CVS_LSTAT in the cvs-1.11.2 source, so
use of lstat() appears deliberate.  Why does CVS use lstat() instead of
stat()?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]