New NFSv4 export option "HideFilesBeginningInDot"?

New NFSv4 export option "HideFilesBeginningInDot"?

[Cedric Blancher]

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.

Before I start writing a patch, are there any objections?

Ced
--
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

Re: New NFSv4 export option "HideFilesBeginningInDot"?

[Chuck Lever III]

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.


> 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).


--
Chuck Lever

Re: New NFSv4 export option "HideFilesBeginningInDot"?

[Jeff Layton]

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>