[02/12] statx: Provide IOC flags for Windows fs attributes
diff mbox

Message ID 20151120145447.18930.5308.stgit@warthog.procyon.org.uk
State New
Headers show

Commit Message

David Howells Nov. 20, 2015, 2:54 p.m. UTC
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().

Signed-off-by: David Howells <dhowells@redhat.com>
---

 include/uapi/linux/fs.h |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)


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

Comments

Theodore Y. Ts'o Nov. 24, 2015, 7:52 p.m. UTC | #1
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-cifs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Howells Nov. 26, 2015, 3:35 p.m. UTC | #2
Theodore Ts'o <tytso@mit.edu> wrote:

> 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.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Howells Nov. 26, 2015, 4:01 p.m. UTC | #3
David Howells <dhowells@redhat.com> wrote:

> > 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.

Or as Dave Chinner suggested, I can put them elsewhere and let the FS deal
with them in its own way.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andreas Dilger Nov. 26, 2015, 10:10 p.m. UTC | #4
On Nov 26, 2015, at 8:35 AM, David Howells <dhowells@redhat.com> wrote:
> 
> Theodore Ts'o <tytso@mit.edu> wrote:
> 
>> 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

Patch
diff mbox

diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 9b964a5920af..a195287b8744 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -197,10 +197,13 @@  struct inodes_stat_t {
 #define FS_EXTENT_FL			0x00080000 /* Extents */
 #define FS_DIRECTIO_FL			0x00100000 /* Use direct i/o */
 #define FS_NOCOW_FL			0x00800000 /* Do not cow file */
+#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 */
 #define FS_RESERVED_FL			0x80000000 /* reserved for ext2 lib */
 
-#define FS_FL_USER_VISIBLE		0x0003DFFF /* User visible flags */
-#define FS_FL_USER_MODIFIABLE		0x000380FF /* User modifiable flags */
+#define FS_FL_USER_VISIBLE		0x7003DFFF /* User visible flags */
+#define FS_FL_USER_MODIFIABLE		0x700380FF /* User modifiable flags */
 
 
 #define SYNC_FILE_RANGE_WAIT_BEFORE	1