Re: New NFSv4 export option "HideFilesBeginningInDot"?

[Jeff Layton <jlayton@kernel.org>]

On Sun, 2024-10-06 at 16:45 +0000, Chuck Lever III wrote:
> Copying Volker; maybe he has some thoughts about how
> this might work with Samba on Linux.
> 
> 
> > On Oct 6, 2024, at 2:53 AM, Cedric Blancher <cedric.blancher@gmail.com> wrote:
> > 
> > Good morning!
> > 
> > Windows Server 2022 has a NFS export option called
> > "HideFilesBeginningInDot", which sets the NFS WORD0_HIDDEN flag if a
> > file starts with a '.' character.
> > https://learn.microsoft.com/en-us/powershell/module/nfs/set-nfsserverconfiguration?view=windowsserver2022-ps
> > has some documentation on this.
> > 
> > We'd like to get the same functionality for Linux nfsd, enabled by
> > default ("NoHideFilesBeginningInDot" to turn it off), as a mount
> > option.
> 
> I'm assuming you mean "export option" here, not "mount
> option."
> 
> I'm not sure whether enabling the new behavior by
> default is OK, by Linux rules of not introducing
> behavior regressions. Will ponder.
>

It's a change in behavior, but I'd expect that the Linux client (and
probably other unix clients like BSD) just ignores this attribute.

> 
> > Before I start writing a patch, are there any objections?
> 
> Not an objection, but here are some things to consider
> as you prototype.
> 
> You might be planning to store this not as an actual file
> attribute (retrieved via vfs_getattr or vfs_getxattr) but
> instead NFSD would construct attribute 25 based on whether
> the file name begins with dot and the new export option is
> set.
> 
> On Linux, file names are kept in the parent directory, not
> with the file; and note that a file can have more than one
> name (directory entry) that refers to it.
> 
> Thus it might be difficult to retrieve the file's name
> inside of nfsd4_getattr(), let alone retrieve it
> efficiently, since GETATTR is a frequent operation.
> 
> You will need a deterministic mechanism to resolve the
> ambiguity if the file has multiple names, only some of
> which begin with a dot. Maybe -- only if all of the file's
> names begin with a dot, then it is marked HIDDEN?
> 
> You will have to do something about SETATTR. RFC 8881 shows
> that HIDDEN is a r/w attribute, and IIUC what you are
> proposing is a r/o attribute -- clients cannot change this
> setting via SETATTR. I'm not sure, but probably NFSD's
> SETATTR will need to clear the HIDDEN bit and otherwise
> ignore it. I haven't found any spec language that addresses
> how a server needs to behave if it supports a RECOMMENDED
> r/w attribute but does not permit it to be modified by
> clients.
> 
> Given these issues, perhaps that explains why the Microsoft
> documentation you provided says only:
> 
> "Specifies whether an NFS server creates files that have
> names that begin with a dot (.) as hidden files."
> 
> That is, it appears that the Windows server sets the
> HIDDEN attribute on the file inode at creation time. That
> has it's own set of issues for Linux, since our file
> systems don't implement a HIDDEN attribute (that I know
> of).
> 

Windows has also traditionally not supported hardlinks, so it's fairly
simple to set this attribute correctly there. Hiddenness on unix-like
operating systems is really a characteristic of the filename and not an
inode-level attribute like you're trying to make the server report, so
this is conceptually more difficult.

I think Chuck raises some interesting questions. In particular, if I
have a file that has one hardlink "foo" and another of ".foo", should
it be considered HIDDEN?
 
-- 
Jeff Layton <jlayton@kernel.org>