This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: File creation time oddity (new findings)


-----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@byu.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]