Re: utimes() vs. close()

[Eric Blake]

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

According to Paul Eggert on 10/19/2005 1:45 PM:
> 
>>I was unable to determine from POSIX if this behavior is permissable
>>(close changing the timestamps of an open file descriptor
> 
> 
> There wouldn't be much point to futimes() if the behavior were permitted.
> 
> POSIX is pretty careful in specifying when st_atime, st_mtime, and
> st_ctime can be changed (see, e.g., readdir()).  POSIX doesn't grant
> permission for close() to change these times, so close() shouldn't
> change the times.  This is independent of whether utimes() was called.

The problem was that POSIX couches the updates in terms of 'scheduling
mtime for update', so cygwin's implementation was setting a bit in the
open file that an update was scheduled, then performing the update at
close().  What was then happening is that utimes() changed the time, but
wasn't affecting the state of any open descriptors, so close() was still
seeing the mark to update mtime and changing the time again.  CVS cygwin
has now been patched so that utimes() first searches for open file
descriptors visiting the same name, so that utimes() can clear the
scheduled update and close() no longer interferes, so no patch is needed
to coreutils.

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

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

iD8DBQFDV4ki84KuGfSFAYARApT0AKC4Si4/bFL2StoQrGz00GAhRdUP3wCcDqd/
0nYYtuUVrMXd3kEEEH5UYww=
=uZdJ
-----END PGP SIGNATURE-----