linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Revised statx(2) man page for review
@ 2017-04-25 11:14 Michael Kerrisk (man-pages)
       [not found] ` <f3ef2be8-dfa5-e1dd-2315-d787a2a2acc3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 11+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-04-25 11:14 UTC (permalink / raw)
  To: David Howells
  Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Jeff Layton, lkml,
	Linux API, linux-man

Hello David, et al.,

I merged your statx(2) page, and edited somewhat heavily.
(The merged page source has been pushed to Git.)

Could you please carefully review the text below, in case 
I added any errors.

There is one question in a FIXME below. Could you please
take a look at that also.

Your proposed page duplicated a lot of content from stat(2).
I like to avoid such redundancy, so I move the common pieces
into a new page, inode(7), and reworked stat(2) and statx(2).

Cheers,

Michael



NAME
       statx - get file status (extended)

SYNOPSIS
       #include <sys/types.h>
       #include <sys/stat.h>
       #include <unistd.h>
       #include <fcntl.h>           /* Definition of AT_* constants */

       int statx(int dirfd, const char *pathname, int flags,
                 unsigned int mask, struct statx *buf);

       Note: There is no glibc wrapper for renameat2(); see NOTES.

DESCRIPTION
       This  function  returns information about a file, storing it in
       the buffer pointed to by buf.  The returned buffer is a  struc‐
       ture of the following type:

           struct statx {
               __u32 stx_mask;        /* Mask of bits indicating
                                         filled fields */
               __u32 stx_blksize;     /* Block size for filesystem I/O */
               __u64 stx_attributes;  /* Extra file attribute indicators */
               __u32 stx_nlink;       /* Number of hard links */
               __u32 stx_uid;         /* User ID of owner */
               __u32 stx_gid;         /* Group ID of owner */
               __u16 stx_mode;        /* File type and mode */
               __u64 stx_ino;         /* Inode number */
               __u64 stx_size;        /* Total size in bytes */
               __u64 stx_blocks;      /* Number of 512B blocks allocated */

               /* The following fields are file timestamps */
               struct statx_timestamp stx_atime;  /* Last access */
               struct statx_timestamp stx_btime;  /* Creation */
               struct statx_timestamp stx_ctime;  /* Last status change */
               struct statx_timestamp stx_mtime;  /* Last modification */

               /* If this file represents a device, then the next two
                  fields contain the ID of the device */
               __u32 stx_rdev_major;  /* Major ID */
               __u32 stx_rdev_minor;  /* Minor ID */

               /* The next two fields contain the ID of the device
                  containing the filesystem where the file resides */
               __u32 stx_dev_major;   /* Major ID */
               __u32 stx_dev_minor;   /* Minor ID */
           };

       The file timestamps are structures of the following type:

           struct statx_timestamp {
               __s64 tv_sec;    /* Seconds since the Epoch (UNIX time) */
               __s32 tv_nsec;   /* Nanoseconds before or since tv_sec */
           };

       (Note that reserved space and padding is omitted.)

   Invoking statx():
       To  access  a file's status, no permissions are required on the
       file itself, but in the case of statx() with a  pathname,  exe‐
       cute  (search) permission is required on all of the directories
       in pathname that lead to the file.

       statx() uses pathname, dirfd, and  flags  identify  the  target
       file in one of the following ways:

       An absolute pathname
              If  pathname begins with a slash, then it is an absolute
              pathname that identifies the target file.  In this case,
              dirfd is ignored.

       A relative pathname
              If  pathname  is  a  string that begins with a character
              other than a slash and dirfd is AT_FDCWD, then  pathname
              is  a  relative pathname that is interpreted relative to
              the process's current working directory.

       A pathname interpreted relative to a directory file descriptor
              If pathname is a string that  begins  with  a  character
              other  than  a slash and dirfd is a file descriptor that
              refers to a directory, then pathname is a relative path‐
              name  that  is  interpreted  relative  to  the directory
              referred to by dirfd.

       By file descriptor
              If pathname is NULL, then the target  file  is  the  one
              referred  to  by  the  file descriptor dirfd.  dirfd may
              refer to any type of file, not just a  directory.   (The
              AT_EMPTY_PATH  flag  described  below  provides  similar
              functionality.)


              ┌─────────────────────────────────────────────────────┐
              │FIXME                                                │
              ├─────────────────────────────────────────────────────┤
              │It appears that there  are  two  different  ways  of │
              │doing  the  same  thing:  specifying  the file to be │
              │stat'ed via a file descriptor.  Either,  we  specify │
              │'pathname'  as  NULL, or we specify 'pathname' as an │
              │empty string and  include  the  AT_EMPTY_PATH  flag. │
              │What's  the  rationale  for having two ways of doing │
              │this?                                                │
              └─────────────────────────────────────────────────────┘

       flags can be used to  influence  a  pathname-based  lookup.   A
       value  for  flags is constructed by ORing together zero or more
       of the following constants:

       AT_EMPTY_PATH
              If pathname is an empty  string,  operate  on  the  file
              referred to by dirfd (which may have been obtained using
              the open(2) O_PATH flag).  If  dirfd  is  AT_FDCWD,  the
              call operates on the current working directory.  In this
              case, dirfd can refer to any type of file,  not  just  a
              directory.    This   flag   is   Linux-specific;  define
              _GNU_SOURCE to obtain its definition.

       AT_NO_AUTOMOUNT
              Don't automount the terminal ("basename")  component  of
              pathname  if  it  is  a  directory  that is an automount
              point.  This allows the caller to gather  attributes  of
              an  automount  point  (rather than the location it would
              mount).  This flag can be used in tools that scan direc‐
              tories  to  prevent  mass-automounting of a directory of
              automount  points.   The  AT_NO_AUTOMOUNT  flag  has  no
              effect if the mount point has already been mounted over.
              This  flag  is  Linux-specific;  define  _GNU_SOURCE  to
              obtain its definition.

       AT_SYMLINK_NOFOLLOW
              If  pathname  is a symbolic link, do not dereference it:
              instead return information about the link  itself,  like
              lstat(2).

       flags  can also be used to control what sort of synchronization
       the kernel will do when querying a file on a remote filesystem.
       This is done by ORing in one of the following values:

       AT_STATX_SYNC_AS_STAT
              Do  whatever  stat(2)  does.  This is the default and is
              very much filesystem specific.

       AT_STATX_FORCE_SYNC
              Force the attributes to be synchronized with the server.
              This  may  require  that  a network filesystem perform a
              data writeback to get the timestamps correct.

       AT_STATX_DONT_SYNC
              Don't synchronize anything, but rather just  take  what‐
              ever  the  system has cached if possible.  This may mean
              that the information returned is approximate, but, on  a
              network  filesystem,  it may not involve a round trip to
              the server - even if no lease is held.

       The mask argument to statx() is used to tell the  kernel  which
       fields  the  caller is interested in.  mask is an ORed combina‐
       tion of the following constants:

           STATX_TYPE          Want stx_mode & S_IFMT
           STATX_MODE          Want stx_mode & ~S_IFMT
           STATX_NLINK         Want stx_nlink
           STATX_UID           Want stx_uid
           STATX_GID           Want stx_gid
           STATX_ATIME         Want stx_atime
           STATX_MTIME         Want stx_mtime
           STATX_CTIME         Want stx_ctime
           STATX_INO           Want stx_ino
           STATX_SIZE          Want stx_size
           STATX_BLOCKS        Want stx_blocks
           STATX_BASIC_STATS   [All of the above]
           STATX_BTIME         Want stx_btime
           STATX_ALL           [All currently available fields]

       Note the kernel does not reject values in mask other  than  the
       above.   Instead, it simply informs the caller which values are
       supported by this kernel and filesystem via the  statx.stx_mask
       field.  Therefore, do not simply set mask to UINT_MAX (all bits
       set), as one or more bits may, in the future, be used to  spec‐
       ify an extension to the buffer.

   The returned information
       The  status  information for the target file is returned in the
       statx structure  pointed  to  by  buf.   Included  in  this  is
       stx_mask  which  indicates  what  other  information  has  been
       returned.  stx_mask has the same format as  the  mask  argument
       and  bits  are  set  in  it  to indicate which fields have been
       filled in.

       It should be noted that  the  kernel  may  return  fields  that
       weren't  requested  and  may  fail  to  return fields that were
       requested, depending on what the backing  filesystem  supports.
       In either case, stx_mask will not be equal mask.

       If a filesystem does not support a field or if it has an unrep‐
       resentable value (for instance, a file with  an  exotic  type),
       then  the  mask bit corresponding to that field will be cleared
       in stx_mask even if the user asked for it  and  a  dummy  value
       will  be  filled in for compatibility purposes if one is avail‐
       able (e.g., a dummy UID and GID may be specified to mount under
       some circumstances).

       A filesystem may also fill in fields that the caller didn't ask
       for if it has values for them available and the information  is
       available at no extra cost.  If this happens, the corresponding
       bits will be set in stx_mask.

       Note: for performance and simplicity reasons, different  fields
       in  the statx structure may contain state information from dif‐
       ferent moments during the execution of the  system  call.   For
       example,  if  stx_mode or stx_uid is changed by another process
       by calling chmod(2) or chown(2), stat() might  return  the  old
       stx_mode  together  with  the  new  stx_uid, or the old stx_uid
       together with the new stx_mode.

       Apart from stx_mask (which is described above), the  fields  in
       the statx structure are:

       stx_mode
              The file type and mode.  See inode(7) for details.

       stx_size
              The  size of the file (if it is a regular file or a sym‐
              bolic link) in bytes.  The size of a  symbolic  link  is
              the length of the pathname it contains, without a termi‐
              nating null byte.

       stx_blocks
              The number of  blocks  allocated  to  the  file  on  the
              medium,  in  512-byte  units.  (This may be smaller than
              stx_size/512 when the file has holes.)

       stx_blksize
              The "preferred" block size for efficient filesystem I/O.
              (Writing  to a file in smaller chunks may cause an inef‐
              ficient read-modify-rewrite.)

       stx_nlink
              The number of hard links on a file.

       stx_uid
              The user ID of the file's owner.

       stx_gid
              The ID of the group that may access the file.

       stx_dev_major and stx_dev_minor
              The device on which this file (inode) resides.

       stx_rdev_major and stx_rdev_minor
              The device that this file (inode) represents if the file
              is of block or character device type.

       stx_attributes
              Further status information about the file (see below for
              more information).

       stx_atime
              The file's last access timestamp.

       stx_btime
              The file's creation timestamp.

       stx_ctime
              The file's last status change timestamp.

       stx_mtime
              The file's last modification timestamp.

       For further information on the above fields, see inode(7).

   File attributes
       The stx_attributes field contains a  set  of  ORed  flags  that
       indicate additional attributes of the file:

       STATX_ATTR_COMPRESSED
              The  file  is  compressed  by  the fs and may take extra
              resources to access.

       STATX_ATTR_IMMUTABLE
              The file cannot be modified: it  cannot  be  deleted  or
              renamed,  no  hard links can be created to this file and
              no data can be written to it.  See chattr(1).

       STATX_ATTR_APPEND
              The file can only be opened in append mode for  writing.
              Random access writing is not permitted.  See chattr(1).

       STATX_ATTR_NODUMP
              File is not a candidate for backup when a backup program
              such as dump(8) is run.  See chattr(1).

       STATX_ATTR_ENCRYPTED
              A key is required for the file to be  encrypted  by  the
              filesystem.

RETURN VALUE
       On  success,  zero  is returned.  On error, -1 is returned, and
       errno is set appropriately.

ERRORS
       EACCES Search permission is denied for one of  the  directories
              in  the path prefix of pathname.  (See also path_resolu‐
              tion(7).)

       EBADF  dirfd is not a valid open file descriptor.

       EFAULT Bad address.

       EINVAL Invalid flag specified in flags.

       ELOOP  Too many symbolic links encountered while traversing the
              pathname.

       ENAMETOOLONG
              pathname is too long.

       ENOENT A  component  of pathname does not exist, or pathname is
              an empty string and AT_EMPTY_PATH was not  specified  in
              flags.

       ENOMEM Out of memory (i.e., kernel memory).

       ENOTDIR
              A  component  of  the  path  prefix of pathname is not a
              directory or pathname is relative and dirfd  is  a  file
              descriptor referring to a file other than a directory.

VERSIONS
       statx() was added to Linux in kernel 4.11.

CONFORMING TO
       statx() is Linux specific.

NOTES
       Glibc  does  not (yet) provide a wrapper for the statx() system
       call; call it using syscall(2).

SEE ALSO
       ls(1), stat(1), access(2), chmod(2), chown(2),  stat(2),  read‐
       link(2), utime(2), capabilities(7), inode(7), symlink(7)


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review
       [not found] ` <f3ef2be8-dfa5-e1dd-2315-d787a2a2acc3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2017-04-25 18:50   ` Silvan Jegen
       [not found]     ` <20170425185032.nohoaxbke7r5w5jt-Ug7NTYnKI+9o9fKphESQjg@public.gmane.org>
  2017-04-25 20:06   ` Dmitry V. Levin
  2017-04-26 11:35   ` Revised statx(2) man page for review [and AT_EMPTY_PATH question] David Howells
  2 siblings, 1 reply; 11+ messages in thread
From: Silvan Jegen @ 2017-04-25 18:50 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages)
  Cc: David Howells, Jeff Layton, lkml, Linux API, linux-man

Hi Michael

On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote:
>
> [...]
>
> Could you please carefully review the text below, in case 
> I added any errors.

Just a few comments below.

 
> [...] 
>
>    Invoking statx():
>        To  access  a file's status, no permissions are required on the
>        file itself, but in the case of statx() with a  pathname,  exe‐
>        cute  (search) permission is required on all of the directories
>        in pathname that lead to the file.
> 
>        statx() uses pathname, dirfd, and  flags  identify  the  target

This should be:

"statx() uses pathname, dirfd, and  flags  *to* identify  the  target"


> [...] 
>
>        AT_STATX_SYNC_AS_STAT
>               Do  whatever  stat(2)  does.  This is the default and is
>               very much filesystem specific.

Since we write "Linux-specific" further above we should probably use

"very much filesystem-specific."

here for consistency.


>        AT_STATX_FORCE_SYNC
>               Force the attributes to be synchronized with the server.
>               This  may  require  that  a network filesystem perform a
>               data writeback to get the timestamps correct.
> 
>        AT_STATX_DONT_SYNC
>               Don't synchronize anything, but rather just  take  what‐
>               ever  the  system has cached if possible.  This may mean
>               that the information returned is approximate, but, on  a
>               network  filesystem,  it may not involve a round trip to
>               the server - even if no lease is held.
> 
>        The mask argument to statx() is used to tell the  kernel  which
>        fields  the  caller is interested in.  mask is an ORed combina‐
>        tion of the following constants:
> 
>            STATX_TYPE          Want stx_mode & S_IFMT
>            STATX_MODE          Want stx_mode & ~S_IFMT
>            STATX_NLINK         Want stx_nlink
>            STATX_UID           Want stx_uid
>            STATX_GID           Want stx_gid
>            STATX_ATIME         Want stx_atime
>            STATX_MTIME         Want stx_mtime
>            STATX_CTIME         Want stx_ctime
>            STATX_INO           Want stx_ino
>            STATX_SIZE          Want stx_size
>            STATX_BLOCKS        Want stx_blocks
>            STATX_BASIC_STATS   [All of the above]
>            STATX_BTIME         Want stx_btime
>            STATX_ALL           [All currently available fields]
> 
>        Note the kernel does not reject values in mask other  than  the

We should probably either insert a colon here

"Note: the kernel does not reject values in mask other  than  the..."

or reformulate the sentence like this.

"Note that the kernel does not reject values in mask other  than  the..."


> [...] 
>
>        stx_gid
>               The ID of the group that may access the file.

This group ID is the gid of the file owner's primary group, no? At least
that's what the field comment in the DESCRIPTION implies.

I think it would be more accurate to write:

"The ID of the file owner's primary group"


> [...] 
> 
>        STATX_ATTR_COMPRESSED
>               The  file  is  compressed  by  the fs and may take extra

We write out 'filesystem' everywhere else so I think we should replace 'fs'
with it here as well.


> CONFORMING TO
>        statx() is Linux specific.

For consistency we should write:

"statx() is Linux-specific".


I wrote the changes in-line but if you prefer I can 'git send-email'
a patch as well.


Cheers and thanks for all the hard work!

Silvan

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review
       [not found]     ` <20170425185032.nohoaxbke7r5w5jt-Ug7NTYnKI+9o9fKphESQjg@public.gmane.org>
@ 2017-04-25 19:40       ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 11+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-04-25 19:40 UTC (permalink / raw)
  To: Silvan Jegen
  Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, David Howells, Jeff Layton,
	lkml, Linux API, linux-man

Hello Silvan,

On 04/25/2017 08:50 PM, Silvan Jegen wrote:
> Hi Michael
> 
> On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote:
>>
>> [...]
>>
>> Could you please carefully review the text below, in case 
>> I added any errors.
> 
> Just a few comments below.
> 
>  
>> [...] 
>>
>>    Invoking statx():
>>        To  access  a file's status, no permissions are required on the
>>        file itself, but in the case of statx() with a  pathname,  exe‐
>>        cute  (search) permission is required on all of the directories
>>        in pathname that lead to the file.
>>
>>        statx() uses pathname, dirfd, and  flags  identify  the  target
> 
> This should be:
> 
> "statx() uses pathname, dirfd, and  flags  *to* identify  the  target"

Fixed.

>> [...] 
>>
>>        AT_STATX_SYNC_AS_STAT
>>               Do  whatever  stat(2)  does.  This is the default and is
>>               very much filesystem specific.
> 
> Since we write "Linux-specific" further above we should probably use
> 
> "very much filesystem-specific."

Fixed.

> here for consistency.
> 
> 
>>        AT_STATX_FORCE_SYNC
>>               Force the attributes to be synchronized with the server.
>>               This  may  require  that  a network filesystem perform a
>>               data writeback to get the timestamps correct.
>>
>>        AT_STATX_DONT_SYNC
>>               Don't synchronize anything, but rather just  take  what‐
>>               ever  the  system has cached if possible.  This may mean
>>               that the information returned is approximate, but, on  a
>>               network  filesystem,  it may not involve a round trip to
>>               the server - even if no lease is held.
>>
>>        The mask argument to statx() is used to tell the  kernel  which
>>        fields  the  caller is interested in.  mask is an ORed combina‐
>>        tion of the following constants:
>>
>>            STATX_TYPE          Want stx_mode & S_IFMT
>>            STATX_MODE          Want stx_mode & ~S_IFMT
>>            STATX_NLINK         Want stx_nlink
>>            STATX_UID           Want stx_uid
>>            STATX_GID           Want stx_gid
>>            STATX_ATIME         Want stx_atime
>>            STATX_MTIME         Want stx_mtime
>>            STATX_CTIME         Want stx_ctime
>>            STATX_INO           Want stx_ino
>>            STATX_SIZE          Want stx_size
>>            STATX_BLOCKS        Want stx_blocks
>>            STATX_BASIC_STATS   [All of the above]
>>            STATX_BTIME         Want stx_btime
>>            STATX_ALL           [All currently available fields]
>>
>>        Note the kernel does not reject values in mask other  than  the
> 
> We should probably either insert a colon here
> 
> "Note: the kernel does not reject values in mask other  than  the..."
> 
> or reformulate the sentence like this.
> 
> "Note that the kernel does not reject values in mask other  than  the..."

I changed to the second suggestion.

> 
> 
>> [...] 
>>
>>        stx_gid
>>               The ID of the group that may access the file.
> 
> This group ID is the gid of the file owner's primary group, no? At least
> that's what the field comment in the DESCRIPTION implies.
> 
> I think it would be more accurate to write:
> 
> "The ID of the file owner's primary group"


I made it:

    This field contains the ID of the group owner of the file.

> 
>> [...] 
>>
>>        STATX_ATTR_COMPRESSED
>>               The  file  is  compressed  by  the fs and may take extra
> 
> We write out 'filesystem' everywhere else so I think we should replace 'fs'
> with it here as well.

Indeed! (Fixed.)

>> CONFORMING TO
>>        statx() is Linux specific.
> 
> For consistency we should write:
> 
> "statx() is Linux-specific".

Fixed.

> I wrote the changes in-line but if you prefer I can 'git send-email'
> a patch as well.

This form of feedback is fine.

> Cheers and thanks for all the hard work!

You're welcome. Thanks for checking it.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review
       [not found] ` <f3ef2be8-dfa5-e1dd-2315-d787a2a2acc3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  2017-04-25 18:50   ` Silvan Jegen
@ 2017-04-25 20:06   ` Dmitry V. Levin
       [not found]     ` <20170425200656.GA30045-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
  2017-04-26 11:35   ` Revised statx(2) man page for review [and AT_EMPTY_PATH question] David Howells
  2 siblings, 1 reply; 11+ messages in thread
From: Dmitry V. Levin @ 2017-04-25 20:06 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages)
  Cc: David Howells, Jeff Layton, lkml, Linux API, linux-man

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote:
[...]
>        The file timestamps are structures of the following type:
> 
>            struct statx_timestamp {
>                __s64 tv_sec;    /* Seconds since the Epoch (UNIX time) */
>                __s32 tv_nsec;   /* Nanoseconds before or since tv_sec */
>            };

Nanoseconds since tv_sec.  The "before tv_sec" is not implemented yet
and I hope nobody is going to implement it for the reasons I mentioned
in https://marc.info/?i=20170422192743.GA17005%40altlinux.org


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review
       [not found]     ` <20170425200656.GA30045-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
@ 2017-04-26  5:42       ` Michael Kerrisk (man-pages)
       [not found]         ` <864d7dbb-9fa7-deb2-e379-8d99a6e8c2aa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 11+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-04-26  5:42 UTC (permalink / raw)
  To: Dmitry V. Levin
  Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, David Howells, Jeff Layton,
	lkml, Linux API, linux-man

On 04/25/2017 10:06 PM, Dmitry V. Levin wrote:
> On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote:
> [...]
>>        The file timestamps are structures of the following type:
>>
>>            struct statx_timestamp {
>>                __s64 tv_sec;    /* Seconds since the Epoch (UNIX time) */
>>                __s32 tv_nsec;   /* Nanoseconds before or since tv_sec */
>>            };
> 
> Nanoseconds since tv_sec.  The "before tv_sec" is not implemented yet
> and I hope nobody is going to implement it for the reasons I mentioned
> in https://marc.info/?i=20170422192743.GA17005%40altlinux.org

Thanks Dmitry. Fixed.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review
       [not found]         ` <864d7dbb-9fa7-deb2-e379-8d99a6e8c2aa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2017-04-26 10:43           ` G. Branden Robinson
  0 siblings, 0 replies; 11+ messages in thread
From: G. Branden Robinson @ 2017-04-26 10:43 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages)
  Cc: Dmitry V. Levin, David Howells, Jeff Layton, lkml, Linux API, linux-man

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

At 2017-04-26T07:42:12+0200, Michael Kerrisk (man-pages) wrote:
> On 04/25/2017 10:06 PM, Dmitry V. Levin wrote:
> > On Tue, Apr 25, 2017 at 01:14:26PM +0200, Michael Kerrisk (man-pages) wrote:
> > [...]
> >>        The file timestamps are structures of the following type:
> >>
> >>            struct statx_timestamp {
> >>                __s64 tv_sec;    /* Seconds since the Epoch (UNIX time) */
> >>                __s32 tv_nsec;   /* Nanoseconds before or since tv_sec */
> >>            };
> > 
> > Nanoseconds since tv_sec.  The "before tv_sec" is not implemented yet
> > and I hope nobody is going to implement it for the reasons I mentioned
> > in https://marc.info/?i=20170422192743.GA17005%40altlinux.org
> 
> Thanks Dmitry. Fixed.

If you give a programmer a signed type, he or she will cheerfully stuff
negative values into it, perhaps to carry out-of-band information as
with IEEE NaNs and tagged pointers.

The user should be admonished against using the full range of the type
in any case ([0, 1e9 - 1]).

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review [and AT_EMPTY_PATH question]
       [not found] ` <f3ef2be8-dfa5-e1dd-2315-d787a2a2acc3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
  2017-04-25 18:50   ` Silvan Jegen
  2017-04-25 20:06   ` Dmitry V. Levin
@ 2017-04-26 11:35   ` David Howells
       [not found]     ` <14390.1493206508-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
  2017-04-26 15:10     ` David Howells
  2 siblings, 2 replies; 11+ messages in thread
From: David Howells @ 2017-04-26 11:35 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages), Alexander Viro
  Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA, Jeff Layton, lkml, Linux API, linux-man


Michael Kerrisk (man-pages) <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

>        Note: There is no glibc wrapper for renameat2(); see NOTES.

statx, not renameat2.

>                __u64 stx_blocks;      /* Number of 512B blocks allocated */

The following needs to be added in here:

		__u64	stx_attributes_mask; /* Mask to show what's supported in stx_attributes */

This indicates what stx_attributes the VFS and filesystem actually support.

>                __s32 tv_nsec;   /* Nanoseconds before or since tv_sec */

If you're going to do Dmitry's suggestion, then this needs to be __u32 and you
should remove "before or".

>        statx() uses pathname, dirfd, and  flags  identify  the  target
>        file in one of the following ways:

"to identify"

>        A pathname interpreted relative to a directory file descriptor

I think this is too wordy for a heading and it almost seems to merge into the
description paragraph since it almost ends at the same right margin.  How
about:

	A directory-relative pathname

>        By file descriptor
>               If pathname is NULL, then the target  file  is  the  one
>               referred  to  by  the  file descriptor dirfd.  dirfd may
>               refer to any type of file, not just a  directory.   (The
>               AT_EMPTY_PATH  flag  described  below  provides  similar
>               functionality.)
> 
>               ┌───────────────────────────────┐
>               │FIXME                                                │
>               ├───────────────────────────────┤
>               │It appears that there  are  two  different  ways  of │
>               │doing  the  same  thing:  specifying  the file to be │
>               │stat'ed via a file descriptor.  Either,  we  specify │
>               │'pathname'  as  NULL, or we specify 'pathname' as an │
>               │empty string and  include  the  AT_EMPTY_PATH  flag. │
>               │What's  the  rationale  for having two ways of doing │
>               │this?                                                │
>               └───────────────────────────────┘

AT_EMPTY_PATH wasn't there back in 2010.  I could eliminate the:

	statx(fd, NULL, 0, ...);

option in favour of:

	statx(fd, "", AT_EMPTY_PATH, ...);

Any thoughts either way, Al?

It would seem that AT_EMPTY_PATH should be redundant, though, since you can
just set the pathname pointer to NULL.

>        The mask argument to statx() is used to tell the  kernel  which
>        fields  the  caller is interested in.  mask is an ORed combina‐
>        tion of the following constants:
> 
>            STATX_TYPE          Want stx_mode & S_IFMT
>	     ...
>            STATX_ALL           [All currently available fields]
> 
>        Note the kernel does not reject values in mask other  than  the
>        above.   Instead, it simply informs the caller which values are
>        supported by this kernel and filesystem via the  statx.stx_mask
>        field.  Therefore, do not simply set mask to UINT_MAX (all bits
>        set), as one or more bits may, in the future, be used to  spec‐
>        ify an extension to the buffer.

Is it worth mentioning STATX__RESERVED here, I wonder?  It's not something
that you can actually use (you'll get EINVAL if you try), and will be renamed
should it become used.

>        It should be noted that  the  kernel  may  return  fields  that
>        weren't  requested  and  may  fail  to  return fields that were
>        requested, depending on what the backing  filesystem  supports.

Maybe add "and can be safely ignored" in there somewhere since this seems to
be upsetting people.

>        If a filesystem does not support a field or if it has an unrep‐
>        resentable value (for instance, a file with  an  exotic  type),
>        then  the  mask bit corresponding to that field will be cleared
>        in stx_mask even if the user asked for it  and  a  dummy  value
>        will  be  filled in for compatibility purposes if one is avail‐
>        able (e.g., a dummy UID and GID may be specified to mount under
>        some circumstances).

I don't promise a dummy value for any "extended" field other than zero.

>        Apart from stx_mask (which is described above), the  fields  in
>        the statx structure are:
> 
>        stx_mode
>               The file type and mode.  See inode(7) for details.
>	 ...

Should this list either be in alphabetical order or offset-in-struct order?

This needs to be added:

	stx_attributes_mask
	      A mask indicating which bits in stx_attributes are supported by
	      the VFS and the filesystem.

>    File attributes
>        The stx_attributes field contains a  set  of  ORed  flags  that
>        indicate additional attributes of the file:

Probably should mention stx_attributes_mask here also.  Perhaps:

       The stx_attributes field contains a set of ORed flags that
       indicate additional attributes of the file.  Note that any
       attribute that is not indicated as supported by
       stx_attributes_mask has no usable value here.  The bits in
       stx_attributes_mask correspond bit-by-bit to stx_attributes.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review [and AT_EMPTY_PATH question]
       [not found]     ` <14390.1493206508-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
@ 2017-04-26 12:13       ` Michael Kerrisk (man-pages)
  2017-04-26 15:53       ` Al Viro
  1 sibling, 0 replies; 11+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-04-26 12:13 UTC (permalink / raw)
  To: David Howells, Alexander Viro
  Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, Jeff Layton, lkml,
	Linux API, linux-man, Dmitry V. Levin

Hello David,

Thanks for your comments. Some questions below.

On 04/26/2017 01:35 PM, David Howells wrote:
> 
> Michael Kerrisk (man-pages) <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>>        Note: There is no glibc wrapper for renameat2(); see NOTES.
> 
> statx, not renameat2.

Already reported, and fixed.

> 
>>                __u64 stx_blocks;      /* Number of 512B blocks allocated */
> 
> The following needs to be added in here:
> 
> 		__u64	stx_attributes_mask; /* Mask to show what's supported in stx_attributes */

Done.

> This indicates what stx_attributes the VFS and filesystem actually support.
> 
>>                __s32 tv_nsec;   /* Nanoseconds before or since tv_sec */
> 
> If you're going to do Dmitry's suggestion, then this needs to be __u32 and you
> should remove "before or".

I think the question is rather: what is going to be done to the API?
Will it be changed as Dmitry suggests?

>>        statx() uses pathname, dirfd, and  flags  identify  the  target
>>        file in one of the following ways:
> 
> "to identify"

Already reported, and fixed.

>>        A pathname interpreted relative to a directory file descriptor
> 
> I think this is too wordy for a heading and it almost seems to merge into the
> description paragraph since it almost ends at the same right margin.  How
> about:
> 
> 	A directory-relative pathname

Yes. Changed as you suggest.

>>        By file descriptor
>>               If pathname is NULL, then the target  file  is  the  one
>>               referred  to  by  the  file descriptor dirfd.  dirfd may
>>               refer to any type of file, not just a  directory.   (The
>>               AT_EMPTY_PATH  flag  described  below  provides  similar
>>               functionality.)
>>
>>               ┌───────────────────────────────┐
>>               │FIXME                                                │
>>               ├───────────────────────────────┤
>>               │It appears that there  are  two  different  ways  of │
>>               │doing  the  same  thing:  specifying  the file to be │
>>               │stat'ed via a file descriptor.  Either,  we  specify │
>>               │'pathname'  as  NULL, or we specify 'pathname' as an │
>>               │empty string and  include  the  AT_EMPTY_PATH  flag. │
>>               │What's  the  rationale  for having two ways of doing │
>>               │this?                                                │
>>               └───────────────────────────────┘
> 
> AT_EMPTY_PATH wasn't there back in 2010.  I could eliminate the:
> 
> 	statx(fd, NULL, 0, ...);
> 
> option in favour of:
> 
> 	statx(fd, "", AT_EMPTY_PATH, ...);
> 
> Any thoughts either way, Al?
> 
> It would seem that AT_EMPTY_PATH should be redundant, though, since you can
> just set the pathname pointer to NULL.

Having two ways to do something is odd, and redundant. Note
of the other APIs that provide this functionality do so
in both ways, AFAIK. It's not a big problem, but certainly
strange. If you settle on having just one, then I'd say
choose AT_EMPTY_PATH.

>>        The mask argument to statx() is used to tell the  kernel  which
>>        fields  the  caller is interested in.  mask is an ORed combina‐
>>        tion of the following constants:
>>
>>            STATX_TYPE          Want stx_mode & S_IFMT
>> 	     ...
>>            STATX_ALL           [All currently available fields]
>>
>>        Note the kernel does not reject values in mask other  than  the
>>        above.   Instead, it simply informs the caller which values are
>>        supported by this kernel and filesystem via the  statx.stx_mask
>>        field.  Therefore, do not simply set mask to UINT_MAX (all bits
>>        set), as one or more bits may, in the future, be used to  spec‐
>>        ify an extension to the buffer.
> 
> Is it worth mentioning STATX__RESERVED here, I wonder?  It's not something
> that you can actually use (you'll get EINVAL if you try), and will be renamed
> should it become used.

Under ERRORS I added:

.TP
.B EINVAL
Reserved flag specified in
.IR mask .

Okay?

>>        It should be noted that  the  kernel  may  return  fields  that
>>        weren't  requested  and  may  fail  to  return fields that were
>>        requested, depending on what the backing  filesystem  supports.
> 
> Maybe add "and can be safely ignored" in there somewhere since this seems to
> be upsetting people.

You say "in there somewhere", but it's not quite clear to me which piece 
this applies to. Could you propose a wording please.
> 
>>        If a filesystem does not support a field or if it has an unrep‐
>>        resentable value (for instance, a file with  an  exotic  type),
>>        then  the  mask bit corresponding to that field will be cleared
>>        in stx_mask even if the user asked for it  and  a  dummy  value
>>        will  be  filled in for compatibility purposes if one is avail‐
>>        able (e.g., a dummy UID and GID may be specified to mount under
>>        some circumstances).
> 
> I don't promise a dummy value for any "extended" field other than zero.

I don't know what you mean to say here. Do you mean some
text in the page should change?

>>        Apart from stx_mask (which is described above), the  fields  in
>>        the statx structure are:
>>
>>        stx_mode
>>               The file type and mode.  See inode(7) for details.
>> 	 ...
> 
> Should this list either be in alphabetical order or offset-in-struct order?

Probably the same order as the struct.
> This needs to be added:
> 
> 	stx_attributes_mask
> 	      A mask indicating which bits in stx_attributes are supported by
> 	      the VFS and the filesystem.

Added.

>>    File attributes
>>        The stx_attributes field contains a  set  of  ORed  flags  that
>>        indicate additional attributes of the file:
> 
> Probably should mention stx_attributes_mask here also.  Perhaps:
> 
>        The stx_attributes field contains a set of ORed flags that
>        indicate additional attributes of the file.  Note that any
>        attribute that is not indicated as supported by
>        stx_attributes_mask has no usable value here.  The bits in
>        stx_attributes_mask correspond bit-by-bit to stx_attributes.

Added. But, what does "no usable value here" mean? (The relationship
between stx_attributes_mask and stx_attributes still isn't
so clear to me.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review [and AT_EMPTY_PATH question]
  2017-04-26 11:35   ` Revised statx(2) man page for review [and AT_EMPTY_PATH question] David Howells
       [not found]     ` <14390.1493206508-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
@ 2017-04-26 15:10     ` David Howells
       [not found]       ` <20166.1493219435-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
  1 sibling, 1 reply; 11+ messages in thread
From: David Howells @ 2017-04-26 15:10 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages)
  Cc: dhowells, Alexander Viro, Jeff Layton, lkml, Linux API,
	linux-man, Dmitry V. Levin

Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:

> > This indicates what stx_attributes the VFS and filesystem actually support.
> > 
> >>                __s32 tv_nsec;   /* Nanoseconds before or since tv_sec */
> > 
> > If you're going to do Dmitry's suggestion, then this needs to be __u32 and you
> > should remove "before or".
> 
> I think the question is rather: what is going to be done to the API?
> Will it be changed as Dmitry suggests?

I've forwarded Dmitry's patch to this effect.

> Having two ways to do something is odd, and redundant. Note
> of the other APIs that provide this functionality do so
> in both ways, AFAIK. It's not a big problem, but certainly
> strange. If you settle on having just one, then I'd say
> choose AT_EMPTY_PATH.

If I choose that, I presume I would have to give EINVAL if the path is NULL or
anything other than ""?

> Under ERRORS I added:
> 
> .TP
> .B EINVAL
> Reserved flag specified in
> .IR mask .
> 
> Okay?

That's fine.

> >>        It should be noted that  the  kernel  may  return  fields  that
> >>        weren't  requested  and  may  fail  to  return fields that were
> >>        requested, depending on what the backing  filesystem  supports.
> > 
> > Maybe add "and can be safely ignored" in there somewhere since this seems to
> > be upsetting people.
> 
> You say "in there somewhere", but it's not quite clear to me which piece 
> this applies to. Could you propose a wording please.

Can you do footnotes in roff?

	It should be noted that  the  kernel  may  return  fields  that
	weren't  requested[*]  and  may  fail  to  return fields that were
	requested, depending on what the backing  filesystem  supports.

	[*] These can be safely ignored.

Or maybe:

	It should be noted that  the  kernel  may  return  fields  that
	weren't  requested  and  may  fail  to  return fields that were
	requested, depending on what the backing  filesystem  supports.
	Fields that are given values despite being unrequested can just
	be ignored.

> >>        If a filesystem does not support a field or if it has an unrep‐
> >>        resentable value (for instance, a file with  an  exotic  type),
> >>        then  the  mask bit corresponding to that field will be cleared
> >>        in stx_mask even if the user asked for it  and  a  dummy  value
> >>        will  be  filled in for compatibility purposes if one is avail‐
> >>        able (e.g., a dummy UID and GID may be specified to mount under
> >>        some circumstances).
> > 
> > I don't promise a dummy value for any "extended" field other than zero.
> 
> I don't know what you mean to say here. Do you mean some
> text in the page should change?

The paragraph promises a "dummy value will be filled in for compatibility
purposes if one is available", but doesn't place any restriction on the fields
towhich this applies.  This is only true of the basic stat fields; all other
fields will be cleared if not set.

Maybe we can just leave this as is.  We're not promising a dummy field will
*always* be emplaced.  We can always say that they're just not available for
extended fields if someone asks.

Maybe the best thing to do is to simply add "and cleared otherwise." to the
end of the paragraph.

> > Should this list either be in alphabetical order or offset-in-struct order?
> 
> Probably the same order as the struct.

Sounds good.

> Added. But, what does "no usable value here" mean? (The relationship
> between stx_attributes_mask and stx_attributes still isn't
> so clear to me.

It's not so obvious with the bits that are currently defined.  But I have a
patch that adds Windows attribute bits also (for cifs, ntfs, fat, ...).  What
does it mean, say, if the archive bit is clear?  Does it mean that archive
isn't set in the fs or that the fs doesn't support it?

Further, I have plans to add a 'setattrx' syscall that takes a statx struct
and calls notify_change() with its contents in the kernel.  If I do that, I
need to indicate to notify_change() what changes should be effected.  stx_mask
covers most of the fields, but not stx_attributes.  Some of these attributes
would be alterable.

Would you prefer it to be reverted for the moment?

David

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review [and AT_EMPTY_PATH question]
       [not found]     ` <14390.1493206508-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
  2017-04-26 12:13       ` Michael Kerrisk (man-pages)
@ 2017-04-26 15:53       ` Al Viro
  1 sibling, 0 replies; 11+ messages in thread
From: Al Viro @ 2017-04-26 15:53 UTC (permalink / raw)
  To: David Howells
  Cc: Michael Kerrisk (man-pages), Jeff Layton, lkml, Linux API, linux-man

On Wed, Apr 26, 2017 at 12:35:08PM +0100, David Howells wrote:

> AT_EMPTY_PATH wasn't there back in 2010.  I could eliminate the:
> 
> 	statx(fd, NULL, 0, ...);
> 
> option in favour of:
> 
> 	statx(fd, "", AT_EMPTY_PATH, ...);
> 
> Any thoughts either way, Al?
> 
> It would seem that AT_EMPTY_PATH should be redundant, though, since you can
> just set the pathname pointer to NULL.

NULL pathname pointer means an error for a lot of existing syscalls, so
if you want to turn them into wrappers for ...at() ones at libc level,
you'd need to do special-casing of NULL both kernel-side and in libc wrappers.

Requiring "" + AT_EMPTY_PATH means a single dereference of userland pointer.  
OTOH, that's not a terrible burden...
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Revised statx(2) man page for review [and AT_EMPTY_PATH question]
       [not found]       ` <20166.1493219435-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
@ 2017-04-26 19:08         ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 11+ messages in thread
From: Michael Kerrisk (man-pages) @ 2017-04-26 19:08 UTC (permalink / raw)
  To: David Howells
  Cc: Alexander Viro, Jeff Layton, lkml, Linux API, linux-man, Dmitry V. Levin

Hi David,

On 26 April 2017 at 17:10, David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Michael Kerrisk (man-pages) <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> > This indicates what stx_attributes the VFS and filesystem actually support.
>> >
>> >>                __s32 tv_nsec;   /* Nanoseconds before or since tv_sec */
>> >
>> > If you're going to do Dmitry's suggestion, then this needs to be __u32 and you
>> > should remove "before or".
>>
>> I think the question is rather: what is going to be done to the API?
>> Will it be changed as Dmitry suggests?
>
> I've forwarded Dmitry's patch to this effect.

The man page now corresponds.

>> Having two ways to do something is odd, and redundant. Note
>> of the other APIs that provide this functionality do so
>> in both ways, AFAIK. It's not a big problem, but certainly
>> strange. If you settle on having just one, then I'd say
>> choose AT_EMPTY_PATH.
>
> If I choose that, I presume I would have to give EINVAL if the path is NULL or
> anything other than ""?

AFAICS, just set lookup_flags to include LOOKUP_EMPTY and
getname_flags() does the rest. (Essentially, AT_EMPTY_PATH is a safety
catch for an empty path: if the path is nonempty, it is interpreted as
usual, othewise if it is empty, you get ENOENT unless AT_EMPTY_PATH is
also set.

>> Under ERRORS I added:
>>
>> .TP
>> .B EINVAL
>> Reserved flag specified in
>> .IR mask .
>>
>> Okay?
>
> That's fine.

Thanks.

>> >>        It should be noted that  the  kernel  may  return  fields  that
>> >>        weren't  requested  and  may  fail  to  return fields that were
>> >>        requested, depending on what the backing  filesystem  supports.
>> >
>> > Maybe add "and can be safely ignored" in there somewhere since this seems to
>> > be upsetting people.
>>
>> You say "in there somewhere", but it's not quite clear to me which piece
>> this applies to. Could you propose a wording please.
>
> Can you do footnotes in roff?
>
>         It should be noted that  the  kernel  may  return  fields  that
>         weren't  requested[*]  and  may  fail  to  return fields that were
>         requested, depending on what the backing  filesystem  supports.
>
>         [*] These can be safely ignored.
>
> Or maybe:
>
>         It should be noted that  the  kernel  may  return  fields  that
>         weren't  requested  and  may  fail  to  return fields that were
>         requested, depending on what the backing  filesystem  supports.
>         Fields that are given values despite being unrequested can just
>         be ignored.

I took the second approach.

>> >>        If a filesystem does not support a field or if it has an unrep‐
>> >>        resentable value (for instance, a file with  an  exotic  type),
>> >>        then  the  mask bit corresponding to that field will be cleared
>> >>        in stx_mask even if the user asked for it  and  a  dummy  value
>> >>        will  be  filled in for compatibility purposes if one is avail‐
>> >>        able (e.g., a dummy UID and GID may be specified to mount under
>> >>        some circumstances).
>> >
>> > I don't promise a dummy value for any "extended" field other than zero.
>>
>> I don't know what you mean to say here. Do you mean some
>> text in the page should change?
>
> The paragraph promises a "dummy value will be filled in for compatibility
> purposes if one is available", but doesn't place any restriction on the fields
> towhich this applies.  This is only true of the basic stat fields; all other
> fields will be cleared if not set.
>
> Maybe we can just leave this as is.  We're not promising a dummy field will
> *always* be emplaced.  We can always say that they're just not available for
> extended fields if someone asks.
>
> Maybe the best thing to do is to simply add "and cleared otherwise." to the
> end of the paragraph.

Two points:
* You do realize the text about "dummy values" was your original text?
* Adding "and cleared otherwise" to end of the paragraph doesn't make
sense. I'll leave the text as is, but if you want to propose a more
complete phrasing, let me know.

>> > Should this list either be in alphabetical order or offset-in-struct order?
>>
>> Probably the same order as the struct.
>
> Sounds good.

Already done.

>> Added. But, what does "no usable value here" mean? (The relationship
>> between stx_attributes_mask and stx_attributes still isn't
>> so clear to me.
>
> It's not so obvious with the bits that are currently defined.  But I have a
> patch that adds Windows attribute bits also (for cifs, ntfs, fat, ...).  What
> does it mean, say, if the archive bit is clear?  Does it mean that archive
> isn't set in the fs or that the fs doesn't support it?
>
> Further, I have plans to add a 'setattrx' syscall that takes a statx struct
> and calls notify_change() with its contents in the kernel.  If I do that, I
> need to indicate to notify_change() what changes should be effected.  stx_mask
> covers most of the fields, but not stx_attributes.  Some of these attributes
> would be alterable.
>
> Would you prefer it to be reverted for the moment?

To what does "it" refer?

Anyway, I think we do need some better text describing these two
fields and the difference between them. Can you come up with
something?

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2017-04-26 19:08 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-25 11:14 Revised statx(2) man page for review Michael Kerrisk (man-pages)
     [not found] ` <f3ef2be8-dfa5-e1dd-2315-d787a2a2acc3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-25 18:50   ` Silvan Jegen
     [not found]     ` <20170425185032.nohoaxbke7r5w5jt-Ug7NTYnKI+9o9fKphESQjg@public.gmane.org>
2017-04-25 19:40       ` Michael Kerrisk (man-pages)
2017-04-25 20:06   ` Dmitry V. Levin
     [not found]     ` <20170425200656.GA30045-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org>
2017-04-26  5:42       ` Michael Kerrisk (man-pages)
     [not found]         ` <864d7dbb-9fa7-deb2-e379-8d99a6e8c2aa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-04-26 10:43           ` G. Branden Robinson
2017-04-26 11:35   ` Revised statx(2) man page for review [and AT_EMPTY_PATH question] David Howells
     [not found]     ` <14390.1493206508-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-04-26 12:13       ` Michael Kerrisk (man-pages)
2017-04-26 15:53       ` Al Viro
2017-04-26 15:10     ` David Howells
     [not found]       ` <20166.1493219435-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-04-26 19:08         ` Michael Kerrisk (man-pages)

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).