Mail Archives: cygwin/2007/08/17/08:53:19
-----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/
- Raw text -