Bug 23333

Summary: cvs uses lstat() not stat() to determine whether file has been modified locally.
Product: [Retired] Red Hat Linux Reporter: David Woodhouse <dwmw2>
Component: cvsAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-11-04 09:30:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch to make time_stamp() do both stat() and lstat() and return the newest mtime none

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!