Bug 23333 - cvs uses lstat() not stat() to determine whether file has been modified locally.
cvs uses lstat() not stat() to determine whether file has been modified locally.
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: cvs (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-04 12:43 EST by David Woodhouse
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-04 04:30:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to make time_stamp() do both stat() and lstat() and return the newest mtime (638 bytes, patch)
2001-01-08 07:08 EST, David Woodhouse
no flags Details | Diff

  None (edit)
Description David Woodhouse 2001-01-04 12:43:47 EST
I have a strange CVS setup, which always used to work but appears to break
under RH7.

I have a Linux kernel tree under CVS, but some files in it are actually
symlinks to files elsewhere (actually in another _separate_ CVS
repository). 

When I modify a file, cvs observes that the timestamp on the _link_ hasn't
changed, and doesn't bother to actually compare. I think CVS ought to be
using (and indeed used to use) stat() instead of lstat().
Comment 1 David Woodhouse 2001-01-08 07:08:45 EST
Created attachment 7244 [details]
patch to make time_stamp() do both stat() and lstat() and return the newest mtime
Comment 2 David Woodhouse 2001-01-08 07:10:35 EST
I've attached a patch which solves the problem. I haven't yet verified that it
doesn't break anything else, but I don't think a false positive from the
timestamp comparison should be a problem. Suboptimal perhaps, but all that'll
actually get compared needlessly will be symlinks, which shouldn't be a great
performance overhead.
Comment 3 David Woodhouse 2001-09-19 18:34:18 EDT
This patch has been in use without mishap since this bug was filed. In fact, I'd
completely forgotten about it till the 7.2 beta 'upgraded' my CVS to a broken
version again. Please could it be merged?
Comment 4 David Woodhouse 2001-11-04 04:29:58 EST
Bug still present in 7.2 final
Comment 5 Nalin Dahyabhai 2002-01-15 11:58:54 EST
This will be merged into cvs-1.11.1p1-6.  Thanks!

Note You need to log in before you can comment on or make changes to this bug.