Bug 23333 - cvs uses lstat() not stat() to determine whether file has been modified locally.
Summary: cvs uses lstat() not stat() to determine whether file has been modified locally.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: cvs
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-04 17:43 UTC by David Woodhouse
Modified: 2007-04-18 16:30 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2001-11-04 09:30:12 UTC
Embargoed:


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 12:08 UTC, David Woodhouse
no flags Details | Diff

Description David Woodhouse 2001-01-04 17:43:47 UTC
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 12:08:45 UTC
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 12:10:35 UTC
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 22:34:18 UTC
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 09:29:58 UTC
Bug still present in 7.2 final

Comment 5 Nalin Dahyabhai 2002-01-15 16:58:54 UTC
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.