Andreas Dilger <adilger@xxxxxxxxx> wrote:
> > (Note that reserved space and padding is ommitted)
>
> Do you think that not including the padding could be problematic for users?
Interesting question. Do you think it would be? I don't see why it should be
a problem, since they shouldn't be touching it anyway. Also, the stat(2)
manpage also gives the same warning and omits padding and doesn't seem to have
been amended.
But if you would prefer, I can put it back.
The only reason I can really see for explicitly including it is to say that
this is where future extensions will go.
> > STATX_ATTR_IMMUTABLE File is marked immutable
> ...
> > STATX_ATTR_APPEND File is append-only
I should copy the definitions in chattr(1).
> To test whether a path is a regular file (for example), one could write:
> .nf
> .in +4n
> rc = statx(AT_FDCWD, pathname, 0, STATX_TYPE, &stx);
> if (stx.stx_mask & STATX_TYPE && S_ISREG(sb.stx_mode)) {
> /* Handle regular file */
> }
Good idea.
> > Because tests of the above form are common, additional macros are defined by
> > POSIX to allow the test of the file type in
> > .I stx_mode
> > to be written more concisely:
>
> Should this all just reference the existing stat(2) man page instead of
> duplicating the whole contents here? This is spending a lot of space
> discussing the stx_mode field which could be avoided.
Possibly. On the other hand, it means that everything you need to refer to is
in one page from the user's PoV. I'm not sure what the best policy on this
is.
If I do defer to stat(2), I do need to make some sort of note that the
examples are different and the field name is stx_mask, not st_mask.
David
