X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Eric Blake <ebb9 AT byu DOT net>
Subject:  Re: AW: timestamp confusion
Date: Wed, 20 Jun 2007 15:21:03 +0000 (UTC)
Lines: 41
Message-ID:  <loom.20070620T170817-772@post.gmane.org>
References:  <D95927B47773164A8149F384F079E56F0F6ACB AT volta DOT lust DOT de>
Mime-Version:  1.0
Content-Type:  text/plain; charset=utf-8
Content-Transfer-Encoding:  8bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
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

Löwis, Johannes <Johannes.Loewis <at> levitec.de> writes:

> 
> Thank you for this information.
> But also with stat the access time of a file is modified on each call
> if the file is in a network directory. Even with 'stat --printf="%x,%y,%z",
> i.e., no information about executability requested.

Actually, the information WAS requested.  The stat(2) syscall always requests 
executability information, in order to accurately fill out the entire struct 
stat, even if stat(1) or ls(1) does not end up altering the output based on the 
full contents of that struct.  You can use strace to see all that takes place 
during stat(2).  In other words, the bug is not in stat(1) or ls(1), but a 
limitation of cygwin running atop Windows remote networks, where the only way 
to obtain stat information on a file appears to involve reading file contents.  
In Linux (and thus cygwin), you have access(2), then stat(2), but no happy 
medium in the middle where you can request only a subset of file metadata 
without wasting time collecting the metadata bits that you won't be using.

However, all hope is not lost.  You can propose a patch to cygwin that will 
restore the atime timestamp of a file back to what it was before this invasive 
stat.  I don't know how likely such a patch is to be accepted, especially if 
adjusting the times to make stat's read of a file not affect atime slows down 
what is already a slow operation, but unless a patch is written and profiled, I 
cannot say for sure how the cygwin maintainers will react to it.  Or maybe 
Windows has some way similar to Linux's O_NOATIME (2.6.8+) to request opening 
files without adjusting the atime?  If so, then that could be used when stat 
needs to open a file to inspect it (for that matter, implementing O_NOATIME in 
general would be cool).

> > Ah, but some versions of find had bugs in this area.  Try the 
> > newest find 4.3.8.
> 
> Maybe I'll try again after upgrading my cygwin installation.

If you still have problems, list an exact command line that you are using, in 
case we can spot something else you should try.

-- 
Eric Blake



--
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/