Date and time stamps of files

Eric Hopper hopper at omnifarious.org
Fri Sep 9 14:27:27 CDT 2005


On Fri, Sep 09, 2005 at 11:59:44AM -0700, Matt Mackall wrote:
> On Fri, Sep 09, 2005 at 11:51:30AM -0700, Eric Hopper wrote:
> > On Fri, Sep 09, 2005 at 11:34:38AM -0700, Matt Mackall wrote:
> > > On Fri, Sep 09, 2005 at 08:15:36PM +0200, Manfred Lotz wrote:
> > > > I observed when I check out older revisions the file date and time
> > > > stamps do not reflect the original date and time stamps when they were
> > > > committed.
> > > > 
> > > > Is it a feature?! I would prefer to have ther original dates and times
> > > > of files. 
> > > 
> > > You're the first person to ask for such a feature. What do other
> > > systems do?
> > 
> > I don't know if svn makes for a good standard to test against, but it
> > doesn't do this.
> 
> Well the question is which timestamp?

$ svn log datautils.c
------------------------------------------------------------------------
r3 | hopper | 2003-02-08 15:44:59 -0800 (Sat, 08 Feb 2003) | 1 line

Initial checkin from Cheyanne.
------------------------------------------------------------------------
$ stat datautils.c
  File: `datautils.c'
  Size: 16602           Blocks: 40         IO Block: 131072 regular file
Device: fd04h/64772d    Inode: 131430      Links: 1
Access: (0644/-rw-r--r--)  Uid: (  xxx/  hopper)   Gid: (  xxx/  hopper)
Access: 2005-09-09 11:40:40.000000000 -0700
Modify: 2005-09-09 11:40:40.000000000 -0700
Change: 2005-09-09 11:40:40.000000000 -0700

-----------------------------------

$ cvs log pydocgen.py

RCS file: /home/hopper/src/cvs/python/pydocgen/pydocgen.py,v
Working file: pydocgen.py
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;     selected revisions: 1
description:
----------------------------
revision 1.1
date: 2001/01/19 20:54:52;  author: hopper;  state: Exp;
First cut at an automatic documentation generator.
=============================================================================
$ stat pydocgen.py
  File: `pydocgen.py'
  Size: 6699            Blocks: 16         IO Block: 131072 regular file
Device: fd04h/64772d    Inode: 131514      Links: 1
Access: (0644/-rw-r--r--)  Uid: (  xxx/  hopper)   Gid: (  xxx/  hopper)
Access: 2005-09-09 11:45:48.000000000 -0700
Modify: 2001-01-19 12:54:52.000000000 -0800
Change: 2005-09-09 11:45:48.000000000 -0700

> This is ctime, presumably. With mtime set to present, so as not to
> upset make.

No, looking at it, for tools that set the date it's the mtime.  atime
and ctime are set to the checkout time.

> More likely, Perforce is copying CVS. But why?

I'm guessing there are timestamp based build environments out there that
depend on this behavior to do the right thing.  Also, on the surface of
it, this seems like the 'correct' behavior, and that make is broken for
doing what it does.

> We could set ctime to commit time, but it doesn't seem worth the
> trouble. And wouldn't be very useful. Per-file dates won't happen.

I think setting the ctime is worse than setting the mtime.  :-) In fact,
looking at the utimes system call, you're not allowed to change it.
There are many backup tools out there that rely on the ctime to detect
if something needs to be backed up, and I think there are some even
deeper things that rely on the ctime being set by the kernel in a
predictable way.


-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper at omnifarious.org  http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.selenic.com/pipermail/mercurial/attachments/20050909/8474b79e/attachment.pgp


More information about the Mercurial mailing list