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@xxxxxxxxx> 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@xxxxxxxxxx>
