| Message ID | 20151120145447.18930.5308.stgit@warthog.procyon.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html