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: AW: timestamp confusion

LÃwis, Johannes <Johannes.Loewis <at>> 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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]