Mail Archives: cygwin/2007/06/20/11:34:42
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/
- Raw text -