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: ctime: creation or change time?


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

According to Corinna Vinschen on 3/3/2005 4:30 AM:
> On Mar  2 13:19, eric@melski.net wrote:
> 
>>In fact, NTFS has no notion of file change time as described in POSIX.  Is there
>>any chance of undoing this change?  An alternative solution might be to simply
>>use the NTFS file modify time for both the mtime and ctime of the file, since
>>those two are almost always updated together anyway.

Not true - some functions that only affect file metadata, such as utimes()
or chown(), only touch the ctime.  Furthermore, mtime can be arbitrarily
set (thanks to utimes()), but the POSIX notion of ctime is that it is
always an accurate snapshot of the last time something changed about a
file, and cannot be arbitrarily changed.  This is handy, for example, when
untarring an archive - it preserves atime and mtime as they were when the
archive was created, but sets ctime to the time the archive was untarred.

> 
> 
> Well, we're trying to be POSIX like, so that's nothing we're going to
> revert.  I guess we're using ctime as change time even more in future.

If you really want the old behavior, then propose a patch that adds an
option to the CYGWIN environment variable.  I envision the following:

CYGWIN="ctime=creation": never touch ctime; let it be the Windows notion
of file creation time

CYGWIN="ctime=file_change": touch ctime for file modifications (chown,
write, utimes, etc.).  This would be the default level, and matches cygwin
1.5.13 behavior.

CYGWIN="ctime=dir_change": touch ctime everywhere that POSIX requires (the
containing directory needs to be touched on creat, rename, unlink, etc.)
This is more time-consuming and not implemented in 1.5.13, because it
requires opening additional directory file handles during the course of
operation, but is necessary for more complete compliance to the standards.

Having said all that, I'm not going to be the one to implement a patch
along those lines.  If the default bothers you, you are free to fix it.

- --
Life is short - so eat dessert first!

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

iD8DBQFCKGiW84KuGfSFAYARAltJAKCwLrlJEqTj1siobEPuNOrgQDxNVQCdGpn/
q65RZygXUMvz3K4MOdMvbxM=
=o+Xc
-----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]