On Mon, 20 Nov 2023 at 15:44, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > > > On Nov 20, 2023, at 6:46 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote: > >> On Sat, 18 Nov 2023 at 12:56, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > >>> > >>> On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote: > >>>> Good morning! > >>>> > >>>> NFSv4 has a "hidden" filesystem object attribute. How can I set that > >>>> on a Linux NFSv4 server, or in a filesystem exported on Linux via > >>>> NFSv4, so that the NFSv4 client gets this attribute for a file? > >>>> > >>> > >>> You can't. RFC 8881 defines that as "TRUE, if the file is considered > >>> hidden with respect to the Windows API." There is no analogous Linux > >>> inode attribute. > >> > >> Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and > >> ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase > >> supports this), and that means we need to be able to set/get and > >> backup/restore these flags on the NFSv4 server side. > >> > > > > No. They would need to be stored in the inode on the server somehow and > > there is no place to store them. These attributes are simply not > > supported by the Linux NFS server. > > To be clear: these attributes are not supported within the Linux > filesystems themselves. NFSD could of course handle these attributes, > but there is simply no mechanism to make them persistent on Linux > filesystems. You have the setfattr/getfattr attributes on Linux, which can easily store such boolean flags. It would also solve the backup and restore issue, as GNU tar supports these via tar --xattrs > > NTFS might be an exception to that, but I believe Linux does not > allow mounted NTFS filesystems to be modified. So again, no way > to make those attributes persistent. New NTFS kernel driver in Linux 6.x supports r/w operation > > But I do wonder how Samba on Linux handles these guys. NFSD should > do something that doesn't conflict with that. Did anyone figure that one out? Ced -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
