Eric Biggers <ebiggers3@xxxxxxxxx> wrote: > > .I Note: > > For performance and simplicity reasons, different fields in the > > .I statx > > structure may contain state information from different moments > > during the execution of the system call. > > For example, if > > .IR stx_mode > > or > > .IR stx_uid > > is changed by another process by calling > > .BR chmod (2) > > or > > .BR chown (2), > > .BR stat () > > might return the old > > .I stx_mode > > together with the new > > .IR stx_uid , > > or the old > > .I stx_uid > > together with the new > > .IR stx_mode . > > This example is confusing because chmod() doesn't change st_uid, and chown() > doesn't ordinarily change st_mode. Doesn't chown() clear the S_ISUID and S_ISGID flags? > A better example would be that if chown() is used to change both the owner > and group, it's possible that statx() would return the new owner paired with > the old group, or the new group paired with the old owner. Or, the new > owner and group could be observed before the new ctime. This is copied more or less verbatim from stat(2), so what you said applies there too. > Also, it seems this note belongs in a BUGS section of the man page, since it > is a bug. No, it's not a bug, exactly. It's a design decision. It might be worth adding an AT_STAT_LOCK flag to synchronise against attribute setting, but it will cost you something in terms of performance - and even then, over a network filesystem it might not achieve anything. > > .SH ERRORS > > .TP > > .B EINVAL > > Invalid flag specified in > > .IR flags . > > Actually, the behavior when specifying invalid flags differs depending on > whether a path is specified. Good point. Should I reject AT_EMPTY_PATH, AT_NO_AUTOMOUNT and AT_SYMLINK_NOFOLLOW if pathname is NULL, I wonder? > > .B ENOENT > > A component of > > .I pathname > > does not exist, or > > .I pathname > > is an empty string. > > is an empty string and AT_EMPTY_PATH was not specified in flags. That needs fixing in stat(2) also. > > .SH SEE ALSO > > .BR ls (1), > > .BR stat (1), > > Shouldn't this link to stat (2), not stat (1)? Depends whether stat(1) ends up using statx() or not. I can take it out for now. David