On Sat, Nov 25, 2023 at 09:52:36AM -0500, Jeff Layton 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). The semantics of dot-files and HIDDEN are not the same, truly. Interestingly, Samba supports a "hide dot files" option: https://www.samba.org/samba/docs/using_samba/ch08.html It also implements a regular expression mechanism for faking HIDDEN based on filename matching. Apparently the Samba folks don't believe the difference between a HIDDEN inode and an obscured directory entry is important. Or perhaps they do this to work around missing local file system support for storing the HIDDEN attribute. I think I still prefer implementing an actual file attribute to store the setting per-file. HIDDEN seems like a characteristic that should be controlled by the file owner or the (client) application that is managing a view of the file's parent directory, and not by a server's administrator. -- Chuck Lever
