From: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org> To: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: arnd-r2nGTMty4D4@public.gmane.org, linux-afs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH 02/12] statx: Provide IOC flags for Windows fs attributes Date: Tue, 24 Nov 2015 14:52:56 -0500 [thread overview] Message-ID: <20151124195256.GB3482@thunk.org> (raw) In-Reply-To: <20151120145447.18930.5308.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu> To: David Howells <dhowells@redhat.com> Cc: arnd@arndb.de, linux-afs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH 02/12] statx: Provide IOC flags for Windows fs attributes Date: Tue, 24 Nov 2015 14:52:56 -0500 [thread overview] Message-ID: <20151124195256.GB3482@thunk.org> (raw) In-Reply-To: <20151120145447.18930.5308.stgit@warthog.procyon.org.uk> 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
next prev parent reply other threads:[~2015-11-24 19:52 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-11-20 14:54 [RFC][PATCH 00/12] Enhanced file stat system call David Howells 2015-11-20 14:54 ` [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding David Howells [not found] ` <20151120145434.18930.89755.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2015-11-24 17:37 ` Andreas Dilger 2015-11-24 17:37 ` Andreas Dilger 2015-11-24 19:36 ` Theodore Ts'o [not found] ` <20151124193646.GA3482-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2015-11-24 20:10 ` Arnd Bergmann 2015-11-24 20:10 ` Arnd Bergmann 2015-11-29 2:45 ` Theodore Ts'o 2015-11-29 2:45 ` Theodore Ts'o [not found] ` <20151129024555.GA31968-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2015-11-29 21:30 ` Arnd Bergmann 2015-11-29 21:30 ` Arnd Bergmann 2015-11-30 14:16 ` Theodore Ts'o [not found] ` <20151130141605.GA4316-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> 2015-11-30 14:37 ` Arnd Bergmann 2015-11-30 14:37 ` Arnd Bergmann 2015-11-30 14:46 ` Elmar Stellnberger 2015-11-26 15:28 ` David Howells 2015-11-26 15:28 ` David Howells 2015-11-20 14:54 ` [PATCH 02/12] statx: Provide IOC flags for Windows fs attributes David Howells [not found] ` <20151120145447.18930.5308.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2015-11-24 19:52 ` Theodore Ts'o [this message] 2015-11-24 19:52 ` Theodore Ts'o 2015-11-26 15:35 ` David Howells [not found] ` <7976.1448552129-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2015-11-26 16:01 ` David Howells 2015-11-26 16:01 ` David Howells 2015-11-26 22:10 ` Andreas Dilger 2015-11-26 22:10 ` Andreas Dilger 2015-11-20 14:54 ` [PATCH 03/12] statx: Add a system call to make enhanced file info available David Howells [not found] ` <20151120145457.18930.79678.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2015-11-24 20:21 ` Dave Chinner 2015-11-24 20:21 ` Dave Chinner 2015-12-04 12:06 ` Pavel Machek 2015-12-04 12:06 ` Pavel Machek 2015-12-21 23:21 ` David Howells 2015-11-20 14:55 ` [PATCH 04/12] statx: AFS: Return enhanced file attributes David Howells 2015-11-20 14:55 ` [PATCH 05/12] statx: Ext4: " David Howells 2015-11-20 14:55 ` [PATCH 06/12] statx: NFS: " David Howells 2015-11-20 14:55 ` [PATCH 07/12] statx: CIFS: Return enhanced attributes David Howells 2015-11-24 17:33 ` Steve French 2015-11-24 17:34 ` Steve French 2015-11-24 17:34 ` Steve French 2015-11-20 14:56 ` [PATCH 08/12] fsinfo: Add a system call to make enhanced filesystem info available David Howells 2015-11-20 14:56 ` [PATCH 09/12] fsinfo: Ext4: Return information through the filesystem info syscall David Howells 2015-11-20 14:56 ` [PATCH 10/12] fsinfo: AFS: " David Howells 2015-11-20 14:56 ` [PATCH 11/12] fsinfo: NFS: " David Howells [not found] ` <20151120145422.18930.72662.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2015-11-20 14:56 ` [PATCH 12/12] fsinfo: CIFS: " David Howells 2015-11-20 14:56 ` David Howells 2015-11-24 8:11 ` [RFC][PATCH 00/12] Enhanced file stat system call Christoph Hellwig 2015-11-24 8:11 ` Christoph Hellwig 2015-11-20 16:19 ` Martin Steigerwald 2015-11-24 8:13 ` Christoph Hellwig 2015-11-24 8:48 ` Martin Steigerwald 2015-11-24 8:50 ` Christoph Hellwig 2015-11-20 16:28 ` David Howells 2015-11-20 16:28 ` David Howells 2015-11-20 16:35 ` Martin Steigerwald [not found] ` <4495.1448036915-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2015-11-25 17:51 ` J. Bruce Fields 2015-11-25 17:51 ` J. Bruce Fields [not found] ` <20151125175153.GA30335-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2015-11-25 19:30 ` Andreas Dilger 2015-11-25 19:30 ` Andreas Dilger 2015-11-20 16:50 ` Casey Schaufler [not found] ` <564F4F4E.8060603-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org> 2015-11-24 8:15 ` Christoph Hellwig 2015-11-24 8:15 ` Christoph Hellwig 2015-11-24 14:43 ` Casey Schaufler 2015-11-24 16:28 ` Andreas Dilger 2015-11-26 15:19 ` David Howells 2015-11-26 22:06 ` Andreas Dilger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20151124195256.GB3482@thunk.org \ --to=tytso-3s7wtutddsa@public.gmane.org \ --cc=arnd-r2nGTMty4D4@public.gmane.org \ --cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=linux-afs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.