On Apr 1 15:32, Paul Eggert via Cygwin wrote: > > > traditionally (and I'm talking about 7th edition Unix) a single > > > output line of 'ls' corresponded to a state obtained atomically from the > > > file system. I realize we can't always do that nowadays but the further we > > > depart from it, the worse 'ls' users will be. > > The link dereferencing is a courtesy of LS, and in no way it is guaranteed > > to > > be stable in a long run. > > Not sure I get the point here. Although 7th edition Unix didn't have > symlinks, the idea that 'stat' should be atomic is valid even in the > presence of symlinks. > > Is your point that 'stat', which follows symlinks, might give results that > don't correspond to any state of the filesystem at any time in the past? If > so, I'm not sure I agree (at least for filesystems that do things atomically > as POSIX requires); if not, then I am not understanding the point.
Requesting ACL information after stat was never atomic, and ACL information wasn't covered by 7th edition Unix. It's ok trying to make the output atomic, I just wonder if that's not too much hassle for not much gain. After all, even the filename could have changed while you call fstat() and acl_get_fd() even while you still have the same file handle open. So you have atomic display of stat and acl information, but the filename you're printing is already wrong. Or the dangling symlink isn't dangling anymore. Or vice versa. And O_PATH is still not standarized, so you should also allow the code to open the file with O_RDONLY, if you're going that way, I think. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
