On Nov 26, 2015, at 8:35 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > > Theodore Ts'o <tytso@xxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
