Re: [PATCH 02/12] statx: Provide IOC flags for Windows fs attributes

[Theodore Ts'o]

On Fri, Nov 20, 2015 at 02:54:47PM +0000, David Howells wrote:
> Provide IOC flags for Windows fs attributes so that they can be retrieved (or
> even altered) using the FS_IOC_[GS]ETFLAGS ioctl and read using statx().

We have a real problem with numberspace used by FS_IOC_[GS]ETFLAGS.
This ioctl was originally defined for use with ext2, but then later on
other file systems decided they wanted to use the same ioctl for their
file system, and so now we have the situation where some of the bits
are used in a way where they are intended to be file system
independent, and some are file system specific.  And ext[234] use
these bits as its on-disk encoding --- which given that
FS_IOC[GS]ETFLAGS was originally ext[234] specific, is understandable,
but it makes things really messy at this point.

So for example, the bits you have chosen are in conflict with ext4's use:

#define EXT4_INLINE_DATA_FL		0x10000000 /* Inode has inline data. */
#define EXT4_PROJINHERIT_FL		0x20000000 /* Create with parents projid */

> +#define FS_HIDDEN_FL			0x10000000 /* Windows hidden file attribute */
> +#define FS_SYSTEM_FL			0x20000000 /* Windows system file attribute */
> +#define FS_ARCHIVE_FL			0x40000000 /* Windows archive file attribute */


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.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/