On Nov 26, 2015, at 8:35 AM, David Howells [off-list ref] wrote:

Theodore Ts'o [off-list ref] wrote:

quoted

As a result, I would suggest that we not try to use the
FS_IOC_[GS]ETFLAGS number scheme for any new interface, so we're at
least not making a bad situation worse.

The only reason why some other file systems have chosen to use
FS_IOC_[GS]ETFLAGS, instead of defining their own ioctl, is so they
can use lsattr/chattr from e2fsprogs instead of creating their own
utility.  But for statx, there isn't a good reason use the same flags
number space.  At the very least, can we use a new flags field for the
Windows file attributes?  It's not like lsattr/chattr has the ability
to set those flags today anyway.  So we might as well use a new flags
field and a new flags numberspace for them.

Hmmm...  I was trying to make it so that these bits would be saved to disk as
part of the IOC flags so that Samba could make use of them.  I guess they'll
have to be stored in an xattr instead.

The flags can be part of the same flags word in the statx() API, and how they
are stored on disk is a filesystem implementation detail.  In some cases, not
all of the flags can be stored on disk (e.g. FAT or whatever) and an error
will be returned.  In other cases they can be stored efficiently as bits in
the inode, and other filesystems may chose to store them as internal xattrs.
That shouldn't be the concern of the statx() syscall.

Cheers, Andreas