From archie@whistle.com Thu Mar 25 13:42:11 1999
Return-Path: <archie@whistle.com>
Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7])
	by hub.freebsd.org (Postfix) with ESMTP id 3A99F14D21
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 25 Mar 1999 13:42:11 -0800 (PST)
	(envelope-from archie@whistle.com)
Received: (from archie@localhost)
	by bubba.whistle.com (8.9.2/8.9.2) id NAA71438;
	Thu, 25 Mar 1999 13:41:52 -0800 (PST)
Message-Id: <199903252141.NAA71438@bubba.whistle.com>
Date: Thu, 25 Mar 1999 13:41:52 -0800 (PST)
From: Archie Cobbs <archie@whistle.com>
Reply-To: archie@whistle.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: cvs update modification time check granularity is 1 second
X-Send-Pr-Version: 3.2

>Number:         10793
>Category:       bin
>Synopsis:       cvs update modification time check granularity is 1 second
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 25 13:50:01 PST 1999
>Closed-Date:    Thu Aug 9 01:40:37 PDT 2001
>Last-Modified:  Sun Aug 12 21:50:22 PDT 2001
>Originator:     Archie Cobbs
>Release:        FreeBSD 3.1-STABLE i386
>Organization:
Whistle Communications, Inc.
>Environment:

	FreeBSD 3.1-stable, probably -current too

>Description:

	When you type "cvs update" cvs uses the timestamp recorded
	in the Entries file to optimize the determination of whether
	a file has been modified or not.

	However, the granularity of this check is only one second, so
	if a file is checked out and modified within the same second,
	cvs will mistakenly report the file as unmodified (and so will
	"cvs diff"), possibly causing a wrong revision of the file
	to be checked in later.

	Yes, this actually happened to me.. what I did was something
	like this:

	  $ rm file.c
	  $ cvs update file.c ; patch < patchfile ; rm file.c.orig

	After doing this "cvs update" reported no modifications, even
	though "file.c" had been patched.

>How-To-Repeat:

	$ rm file.c
	$ cvs update file.c ; patch < patchfile ; rm file.c.orig
	$ cvs update

>Fix:

	The timestamp recorded in the Entries files should include
	the microseconds field obtained from stat(2).

	This could be done in a backward-compatible manner.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: jkoshy 
State-Changed-When: Thu Aug 9 01:40:37 PDT 2001 
State-Changed-Why:  
Please redirect this bug report to the CVS project (http://www.cvshome.org/). 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=10793 

From: jkoshy@FreeBSD.ORG (Joseph Koshy)
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/10793: cvs update modification time check granularity is 1 second 
Date: Sun, 12 Aug 2001 21:47:47 -0700 (PDT)

 A followup (material which I should have added to the PR log the first time 
 round):
 
 One of the problems of keeping a higher resolution timestamp `portably' is
 that the POSIX and SUS specfication only require that `stat(2)' return a
 'time_t' for field `st_mtime'.  `time_t' measures time in "seconds", which
 is what CVS is using.
 
 FreeBSD/NetBSD/and possibly other OSes seem to maintain a higher-resolution
 timestamp, as a `struct timespec', but other OSes don't.
 
 Regards,
 Koshy
 <jkoshy@freebsd.org>
 
 
>Unformatted:
