X-Spam-Check-By: sourceware.org
Message-ID: <46C59A2C.7060901@byu.net>
Date: Fri, 17 Aug 2007 06:53:00 -0600
From: Eric Blake <ebb9 AT byu DOT net>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Ronald Fischer <ronald DOT fischer AT venyon DOT com>, cygwin AT cygwin DOT com
Subject: Re: File creation time oddity (new findings)
References: <387E9FC1619C0849BA8934938037E54F0F5E29 AT sv-muc-004 DOT venyon-mail DOT local> A<loom DOT 20070816T234942-784 AT post DOT gmane DOT org> <387E9FC1619C0849BA8934938037E54F0F5E62 AT sv-muc-004 DOT venyon-mail DOT local>
In-Reply-To: <387E9FC1619C0849BA8934938037E54F0F5E62@sv-muc-004.venyon-mail.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Redirecting to the list - http://cygwin.com/acronyms/#PPIOSPE

According to Ronald Fischer on 8/17/2007 1:46 AM:
>>> ~/thome/tmp $ date
>>> Thu Aug 16 16:49:35     2007
>>> ~/thome/tmp $ ls -l dummy3
>>> -rw-r--r-- 1 rfischer mkgroup-l-d 2 Aug 16 16:42 dummy3
>>>
>>> As you can see, ls -l shows 16:42 for the creation time,
>> No idea why your ctime and mtime disagree - are you sure your 
>> system clock and 
>> BIOS clock match?  
> 
> No - how can I find out? But even then - should not be the same
> clock used for ctime and mtime?
> 
>> Have you recently used an NTP server to 
>> align your clock 
>> with the rest of the world?  
> 
> Yes, I'm setting my system's time via a NTP server, but this
> too can't explain why ctime and mtime are different, can it?

Like I said, I have no idea how ctime would be different from mtime on
file creation.  But as the rest of your mail shows, they aren't different;
instead, it was the difference between ctime/mtime and now that you were
complaining about.

> 
>> However, I want one thing to be 
>> clear - ls does 
>> not list creation time; it lists change time (ctime not stand 
>> for creation time 
>> in POSIX, instead, the BSD notion birthtime, aka Btime, maps 
>> to the Windows 
>> creation time - for full birthtime support in cygwin, you 
>> need to use a 
>> snapshot, as cygwin 1.5.24 does not support querying birthtime).
> 
> Right ... just when you create a new file, change time *is*
> creation time, isn't it?

Yes, creating a new file is supposed to set mtime, ctime, atime, and Btime
all to the same value.

Note that stat(1) does not (yet) list Btime (in part, because doing so
would require you to use a snapshot).

>> Also, stat(1) may be nicer than ls(1) for figuring these 
>> timestamp issues out.
> 
> Good point. I was not aware of stat(1) before. So, here we go:
> 
> ~/tmp $ date
> Fri Aug 17 09:41:30     2007
> ~/tmp $ echo x >dummy5
> ~/tmp $ stat dummy5
>   File: `dummy5'
>   Size: 2               Blocks: 1024       IO Block: 1024   regular file
> Device: 493329f2h/1228089842d   Inode: 286061516451481604  Links: 1
> Access: (0644/-rw-r--r--)  Uid: (115670/rfischer)   Gid:
> (10545/mkgroup-l-d)
> Access: 2007-08-17 09:33:48.000000000 +0200
> Modify: 2007-08-17 09:33:48.000000000 +0200
> Change: 2007-08-17 09:33:48.000000000 +0200
> ~/tmp $ date
> Fri Aug 17 09:41:54     2007
> ~/tmp $ touch dummy5
> ~/tmp $ stat dummy5
>   File: `dummy5'
>   Size: 2               Blocks: 1024       IO Block: 1024   regular file
> Device: 493329f2h/1228089842d   Inode: 286061516451481604  Links: 1
> Access: (0644/-rw-r--r--)  Uid: (115670/rfischer)   Gid:
> (10545/mkgroup-l-d)
> Access: 2007-08-17 09:41:59.000000000 +0200
> Modify: 2007-08-17 09:41:59.000000000 +0200
> Change: 2007-08-17 09:41:59.000000000 +0200

Doesn't happen for me on a local disk:

$ date
Fri Aug 17 06:47:04 MDT 2007
$ touch foo
$ stat foo
  File: `foo'
  Size: 0         	Blocks: 0          IO Block: 1024   regular empty file
Device: 10897b43h/277445443d	Inode: 8444249301410534  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1007/  eblake)   Gid: (  513/    None)
Access: 2007-08-17 06:47:05.708125000 -0600
Modify: 2007-08-17 06:47:05.708125000 -0600
Change: 2007-08-17 06:47:05.703125000 -0600
$ date
Fri Aug 17 06:47:07 MDT 2007

> 
> So the effect seems to be the same as before: As if a different clock
> were used when calculating the time stamps for creating a file, or
> for modifying it.

Hmm, could it be that your files reside on a remote mount, and that NFS is
reflecting the time of the remote machine (ie. the remote machine leads or
lags your machine)?

> 
> BUT I have found something new: The effect occurs ONLY if the file
> resides on the network drive. I tried the same for creating a local
> file on my hard disk, and there timing is correct.

Yep - that clinches it - clock skew between the machines.

> 
> Could it be that file creation times are put into the directory
> in a different way if it is a mapped drive from the network?

It is an artifact of how Windows interacts with remote drives in the
presence of clock skew between the machines.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 AT byu DOT net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxZos84KuGfSFAYARAobkAKCKh2BHSpJBINyssryh1a7YrlfKvwCgxf0r
JZaXBx8XKzZtR+2Y2Vx1zRo=
=Y7U3
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/