Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <420CBCE6.60603@byu.net>
Date: Fri, 11 Feb 2005 07:10:46 -0700
From: Eric Blake <ebb9 AT byu DOT net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: more ctime bugs
References: <020920052127 DOT 27398 DOT 420A803A0009BD7500006B0622007507440A050E040D0C079D0A AT comcast DOT net> <20050211093508 DOT GB27256 AT cygbert DOT vinschen DOT de>
In-Reply-To: <20050211093508.GB27256@cygbert.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

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

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,
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html:

"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             ebb9 AT byu DOT 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

iD8DBQFCDLzm84KuGfSFAYARAo6EAJ9rLGIROa6E9DGFjnaOMQogwDPH+QCfZFmo
xc6CO7xt7ld2lMCIzKDT1H4=
=+k5i
-----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/