This is the mail archive of the
mailing list for the Cygwin project.
Re: more ctime bugs
-----BEGIN PGP SIGNED MESSAGE-----
According to Corinna Vinschen on 2/11/2005 2:35 AM:
> No problem with open and link, but I'm a bit reluctant to do this in
> write. Setting the file time on each WriteFile looks like a pretty
> time consuming operation, so I'm a bit in doubt if every write operation
> should be slowed down by this, POSIX compatibility or not. Wouldn't
> it help in most cases, if the close after write sets the ctime?
That idea is close to what I had in mind. Note that POSIX wording in 4.7
for updating file times,
"An implementation may update fields that are marked for update
immediately, or it may update such fields periodically. At an update point
in time, any marked fields shall be set to the current time and the update
marks shall be cleared. All fields that are marked for update shall be
updated when the file ceases to be open by any process, or when a stat(),
fstat(), or lstat() is performed on the file. Other times at which updates
are done are unspecified. Marks for update, and updates themselves, are
not done for files on read-only file systems; see Read-Only File System."
There is no minimum time specified for the periodic updates, and not even
a requirement that a second process be able to see the updates while the
first process still has the file open and is updating it if the second
process does not stat that file. It is more a requirement that once a
file is changed, stat provides a synchronization point where all processes
can detect that the file has changed.
I really do think that a smarter and faster implementation, that still
complies with POSIX, is to track that atime, mtime, and ctime need updates
as part of the file descriptor, and to not call the Windows SetFileTimes
except as part of utimes (because atime and mtime need not be set to
'now'), and in the stat family and close (but only if the atime, mtime, or
ctime bits had been set). Then chown, truncate, link, write, and so
forth, just need to set the appropriate time-needs-updating bits to let
stat/close do the actual work, saving all the Windows system calls in the
meantime. In fact, since Windows already seems to do a good job of
keeping atime and mtime up-to-date, you may only need cygwin to cache just
a ctime-needs-updating bit.
Life is short - so eat dessert first!
Eric Blake firstname.lastname@example.org
-----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
-----END PGP SIGNATURE-----
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html