Received-SPF: pass (google.com: domain of linux-nfs+bounces-193-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <CALXu0UdcCKBGR8FUSEeEMngKqwz98Xc2HFXnhX5i_1ioEiuaQg@mail.gmail.com>
 <83a30ef92afa05d50232bd3c933f8eb45ed8f98b.camel@kernel.org>
 <CALXu0UerMnjs9y4gQTvy-v-gqSgO2imFbMAZ87LFj1tQqvfjiQ@mail.gmail.com>
 <0d7966163db13d71cb4679d51db5cacf91f42b6b.camel@kernel.org>
 <CALXu0Uf9LiNL7SA57vSq5pMBVBZESWexcRwDR0XMc9fFpPiNkQ@mail.gmail.com>
 <CALXu0UccoNs0A4MjQH7gPboarWyZcRQzsy2zJRxk51LR0hGDVQ@mail.gmail.com>
 <ZWDgvFfkAF8e3MFj@tissot.1015granger.net> <afb9281a81c2001588dbaf46e0ac13fc99ffbb41.camel@kernel.org>
In-Reply-To: <afb9281a81c2001588dbaf46e0ac13fc99ffbb41.camel@kernel.org>
From: Cedric Blancher <cedric.blancher@gmail.com>
Date: Thu, 30 Nov 2023 11:28:00 +0100
Message-ID: <CALXu0UcCzV1g0z6Uka3tKEhJc0MFVj89TzWKeT7upXuOVYWE0Q@mail.gmail.com>
Subject: Re: <DOT>foo gets NFSv4 HIDDEN attribute by default by nfsd? Re: How
 to set the NFSv4 "HIDDEN" attribute on Linux?
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

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.

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