Re: <DOT>foo gets NFSv4 HIDDEN attribute by default by nfsd? Re: How to set the NFSv4 "HIDDEN" attribute on Linux?

[Jeff Layton <jlayton@kernel.org>]

On Thu, 2023-11-30 at 11:28 +0100, Cedric Blancher wrote:
> On Sat, 25 Nov 2023 at 15:52, Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > On Fri, 2023-11-24 at 12:43 -0500, Chuck Lever wrote:
> > > On Thu, Nov 23, 2023 at 11:24:10PM +0100, Cedric Blancher wrote:
> > > > Also, it is legal for a nfsd to give the DOT files (/.foo) the HIDDEN
> > > > attribute by default? Right now on Windows they show up because NFSv4
> > > > HIDDEN is not set, and it is annoying.
> > > 
> > > I suppose an NFS server could do this, but I'm not aware of any
> > > other multi-protocol file server (eg, Oracle ZFS or NetApp) that
> > > does.
> > > 
> > > Dot-files are obscured on POSIX systems by the NFS clients and their
> > > user space (ls and graphical file navigators). I don't see why the
> > > Windows NFS client can't be similarly architected. Or perhaps it
> > > could fabricate the HIDDEN attribute for such files itself.
> > > 
> > > 
> > 
> > Question. GETATTR operates on filehandles, which are roughly analogous
> > to inode with Linux nfsd:
> > 
> > $ touch visible
> > $ ln visible .hidden
> > 
> > Is the resulting inode and filehandle now considered HIDDEN or not?
> > 
> > These kinds of issues are endemic when trying to map MS Windows concepts
> > onto Linux (and vice-versa)
> 
> No, this is actually a good example to show that it *WORKS*.
> 
> 1. Assuming Linux adds support for a user.xattr to set the NFSv4 HIDDEN flag
> 2. Assuming nfsd can give the flag on a per extended regular
> expression basis depending on the filename, which would default to
> "^\..+$" (all files starting with DOT get the NFSv4 HIDDEN flag)
> 
> Then of course [1] overrides [2], which means that the eregex is only
> used if no user.xattr sets the flag.
> 
> In your example the file "visible" does not have the HIDDEN flag set
> (no eregex match), but the hardlink would have that flag set.


Those are some big assumptions.

With #1, we generally don't do this sort of hacky carveout of user
xattrs in nfsd. That sort of thing is fine for a NFS appliance with a
hidden backend filesystem, but ours is a general-purpose server that
serves filesystems that may be locally accessible. We can't know whether
it's safe to use _any_ xattr on any given generic inode.

#2 is not even possible: Consider that we may need to satisfy a GETATTR
request after the server has rebooted. In that case, we may only have
the filehandle for the inode, and may not know any of its filenames yet.

The bottom line is that visibility in Unix/Linux is a property of the
_dentry_, but GETATTR is done against an inode which can be connected to
multiple dentries (some visible and some not). This is different from
Windows where it is a per-inode property (and hardlinks are mostly never
used).

I don't believe we'll ever be able to properly support this flag since
it conceptually just doesn't map onto the Linux filesystem.
-- 
Jeff Layton <jlayton@kernel.org>