Good morning!
NFSv4 has a "hidden" filesystem object attribute. How can I set that
on a Linux NFSv4 server, or in a filesystem exported on Linux via
NFSv4, so that the NFSv4 client gets this attribute for a file?
Ced
--
Cedric Blancher <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
> Good morning!
>
> NFSv4 has a "hidden" filesystem object attribute. How can I set that
> on a Linux NFSv4 server, or in a filesystem exported on Linux via
> NFSv4, so that the NFSv4 client gets this attribute for a file?
>
You can't. RFC 8881 defines that as "TRUE, if the file is considered
hidden with respect to the Windows API." There is no analogous Linux
inode attribute.
Cheers,
--
Jeff Layton <[email protected]>
On Sat, 18 Nov 2023 at 12:56, Jeff Layton <[email protected]> wrote:
>
> On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
> > Good morning!
> >
> > NFSv4 has a "hidden" filesystem object attribute. How can I set that
> > on a Linux NFSv4 server, or in a filesystem exported on Linux via
> > NFSv4, so that the NFSv4 client gets this attribute for a file?
> >
>
> You can't. RFC 8881 defines that as "TRUE, if the file is considered
> hidden with respect to the Windows API." There is no analogous Linux
> inode attribute.
Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and
ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase
supports this), and that means we need to be able to set/get and
backup/restore these flags on the NFSv4 server side.
Ced
--
Cedric Blancher <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote:
> On Sat, 18 Nov 2023 at 12:56, Jeff Layton <[email protected]> wrote:
> >
> > On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
> > > Good morning!
> > >
> > > NFSv4 has a "hidden" filesystem object attribute. How can I set that
> > > on a Linux NFSv4 server, or in a filesystem exported on Linux via
> > > NFSv4, so that the NFSv4 client gets this attribute for a file?
> > >
> >
> > You can't. RFC 8881 defines that as "TRUE, if the file is considered
> > hidden with respect to the Windows API." There is no analogous Linux
> > inode attribute.
>
> Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and
> ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase
> supports this), and that means we need to be able to set/get and
> backup/restore these flags on the NFSv4 server side.
>
No. They would need to be stored in the inode on the server somehow and
there is no place to store them. These attributes are simply not
supported by the Linux NFS server.
--
Jeff Layton <[email protected]>
> On Nov 20, 2023, at 6:46 AM, Jeff Layton <[email protected]> wrote:
>
> On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote:
>> On Sat, 18 Nov 2023 at 12:56, Jeff Layton <[email protected]> wrote:
>>>
>>> On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
>>>> Good morning!
>>>>
>>>> NFSv4 has a "hidden" filesystem object attribute. How can I set that
>>>> on a Linux NFSv4 server, or in a filesystem exported on Linux via
>>>> NFSv4, so that the NFSv4 client gets this attribute for a file?
>>>>
>>>
>>> You can't. RFC 8881 defines that as "TRUE, if the file is considered
>>> hidden with respect to the Windows API." There is no analogous Linux
>>> inode attribute.
>>
>> Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and
>> ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase
>> supports this), and that means we need to be able to set/get and
>> backup/restore these flags on the NFSv4 server side.
>>
>
> No. They would need to be stored in the inode on the server somehow and
> there is no place to store them. These attributes are simply not
> supported by the Linux NFS server.
To be clear: these attributes are not supported within the Linux
filesystems themselves. NFSD could of course handle these attributes,
but there is simply no mechanism to make them persistent on Linux
filesystems.
NTFS might be an exception to that, but I believe Linux does not
allow mounted NTFS filesystems to be modified. So again, no way
to make those attributes persistent.
But I do wonder how Samba on Linux handles these guys. NFSD should
do something that doesn't conflict with that.
--
Chuck Lever
On Mon, 20 Nov 2023 at 15:44, Chuck Lever III <[email protected]> wrote:
>
>
>
> > On Nov 20, 2023, at 6:46 AM, Jeff Layton <[email protected]> wrote:
> >
> > On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote:
> >> On Sat, 18 Nov 2023 at 12:56, Jeff Layton <[email protected]> wrote:
> >>>
> >>> On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
> >>>> Good morning!
> >>>>
> >>>> NFSv4 has a "hidden" filesystem object attribute. How can I set that
> >>>> on a Linux NFSv4 server, or in a filesystem exported on Linux via
> >>>> NFSv4, so that the NFSv4 client gets this attribute for a file?
> >>>>
> >>>
> >>> You can't. RFC 8881 defines that as "TRUE, if the file is considered
> >>> hidden with respect to the Windows API." There is no analogous Linux
> >>> inode attribute.
> >>
> >> Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and
> >> ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase
> >> supports this), and that means we need to be able to set/get and
> >> backup/restore these flags on the NFSv4 server side.
> >>
> >
> > No. They would need to be stored in the inode on the server somehow and
> > there is no place to store them. These attributes are simply not
> > supported by the Linux NFS server.
>
> To be clear: these attributes are not supported within the Linux
> filesystems themselves. NFSD could of course handle these attributes,
> but there is simply no mechanism to make them persistent on Linux
> filesystems.
You have the setfattr/getfattr attributes on Linux, which can easily
store such boolean flags.
It would also solve the backup and restore issue, as GNU tar supports
these via tar --xattrs
>
> NTFS might be an exception to that, but I believe Linux does not
> allow mounted NTFS filesystems to be modified. So again, no way
> to make those attributes persistent.
New NTFS kernel driver in Linux 6.x supports r/w operation
>
> But I do wonder how Samba on Linux handles these guys. NFSD should
> do something that doesn't conflict with that.
Did anyone figure that one out?
Ced
--
Cedric Blancher <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On Mon, 20 Nov 2023 at 12:46, Jeff Layton <[email protected]> wrote:
>
> On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote:
> > On Sat, 18 Nov 2023 at 12:56, Jeff Layton <[email protected]> wrote:
> > >
> > > On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
> > > > Good morning!
> > > >
> > > > NFSv4 has a "hidden" filesystem object attribute. How can I set that
> > > > on a Linux NFSv4 server, or in a filesystem exported on Linux via
> > > > NFSv4, so that the NFSv4 client gets this attribute for a file?
> > > >
> > >
> > > You can't. RFC 8881 defines that as "TRUE, if the file is considered
> > > hidden with respect to the Windows API." There is no analogous Linux
> > > inode attribute.
> >
> > Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and
> > ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase
> > supports this), and that means we need to be able to set/get and
> > backup/restore these flags on the NFSv4 server side.
> >
>
> No. They would need to be stored in the inode on the server somehow and
> there is no place to store them. These attributes are simply not
> supported by the Linux NFS server.
Linux has xattrs, which are per inode, and can be backuped and
restored via tar --xattrs. That would be good enough
Ced
--
Cedric Blancher <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On Wed, 22 Nov 2023 at 23:42, Cedric Blancher <[email protected]> wrote:
>
> On Mon, 20 Nov 2023 at 12:46, Jeff Layton <[email protected]> wrote:
> >
> > On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote:
> > > On Sat, 18 Nov 2023 at 12:56, Jeff Layton <[email protected]> wrote:
> > > >
> > > > On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
> > > > > Good morning!
> > > > >
> > > > > NFSv4 has a "hidden" filesystem object attribute. How can I set that
> > > > > on a Linux NFSv4 server, or in a filesystem exported on Linux via
> > > > > NFSv4, so that the NFSv4 client gets this attribute for a file?
> > > > >
> > > >
> > > > You can't. RFC 8881 defines that as "TRUE, if the file is considered
> > > > hidden with respect to the Windows API." There is no analogous Linux
> > > > inode attribute.
> > >
> > > Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and
> > > ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase
> > > supports this), and that means we need to be able to set/get and
> > > backup/restore these flags on the NFSv4 server side.
> > >
> >
> > No. They would need to be stored in the inode on the server somehow and
> > there is no place to store them. These attributes are simply not
> > supported by the Linux NFS server.
>
> Linux has xattrs, which are per inode, and can be backuped and
> restored via tar --xattrs. That would be good enough
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.
Ced
--
Cedric Blancher <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On Thu, Nov 23, 2023 at 2:24 PM Cedric Blancher
<[email protected]> wrote:
>
> On Wed, 22 Nov 2023 at 23:42, Cedric Blancher <[email protected]> wrote:
> >
> > On Mon, 20 Nov 2023 at 12:46, Jeff Layton <[email protected]> wrote:
> > >
> > > On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote:
> > > > On Sat, 18 Nov 2023 at 12:56, Jeff Layton <[email protected]> wrote:
> > > > >
> > > > > On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
> > > > > > Good morning!
> > > > > >
> > > > > > NFSv4 has a "hidden" filesystem object attribute. How can I set that
> > > > > > on a Linux NFSv4 server, or in a filesystem exported on Linux via
> > > > > > NFSv4, so that the NFSv4 client gets this attribute for a file?
> > > > > >
> > > > >
> > > > > You can't. RFC 8881 defines that as "TRUE, if the file is considered
> > > > > hidden with respect to the Windows API." There is no analogous Linux
> > > > > inode attribute.
> > > >
> > > > Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and
> > > > ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase
> > > > supports this), and that means we need to be able to set/get and
> > > > backup/restore these flags on the NFSv4 server side.
> > > >
> > >
> > > No. They would need to be stored in the inode on the server somehow and
> > > there is no place to store them. These attributes are simply not
> > > supported by the Linux NFS server.
> >
> > Linux has xattrs, which are per inode, and can be backuped and
> > restored via tar --xattrs. That would be good enough
>
> 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.
First, just to let you know, I am not a Linux developer. I work on the FreeBSD
NFS code...
To be honest, you can do just about anything you want in the client. The RFCs
basically define what goes "on the wire".
Now, having said that, you might run into difficulties doing this
because "hidden"
is defined as a RW attribute and to set it would require renaming the file.
rick
>
> Ced
> --
> Cedric Blancher <[email protected]>
> [https://plus.google.com/u/0/+CedricBlancher/]
> Institute Pasteur
>
On Wed, Nov 22, 2023 at 11:42:43PM +0100, Cedric Blancher wrote:
> On Mon, 20 Nov 2023 at 12:46, Jeff Layton <[email protected]> wrote:
> >
> > On Sun, 2023-11-19 at 17:51 +0100, Cedric Blancher wrote:
> > > On Sat, 18 Nov 2023 at 12:56, Jeff Layton <[email protected]> wrote:
> > > >
> > > > On Sat, 2023-11-18 at 07:24 +0100, Cedric Blancher wrote:
> > > > > Good morning!
> > > > >
> > > > > NFSv4 has a "hidden" filesystem object attribute. How can I set that
> > > > > on a Linux NFSv4 server, or in a filesystem exported on Linux via
> > > > > NFSv4, so that the NFSv4 client gets this attribute for a file?
> > > > >
> > > >
> > > > You can't. RFC 8881 defines that as "TRUE, if the file is considered
> > > > hidden with respect to the Windows API." There is no analogous Linux
> > > > inode attribute.
> > >
> > > Can we use setfattr and getfattr to set/get the NFSv4.1 HIDDEN and
> > > ARCHIVE? We have Windows NFSv4 clients (and kofemann/Roland's codebase
> > > supports this), and that means we need to be able to set/get and
> > > backup/restore these flags on the NFSv4 server side.
> > >
> >
> > No. They would need to be stored in the inode on the server somehow and
> > there is no place to store them. These attributes are simply not
> > supported by the Linux NFS server.
>
> Linux has xattrs, which are per inode, and can be backuped and
> restored via tar --xattrs. That would be good enough
This being upstream, we are more concerned with a properly
architected long-term solution rather than a proof of concept.
If Linux were to support them, I would rather see these treated as
first-class file attributes -- such attributes might be used by
Samba, the SMB client, and local accessors as well as NFSD, so they
would need a common and consistent API, through the VFS.
Since they are not POSIX attributes, I think they would have to be
plumbed through statx(), and each file system would need to
determine their own mechanism for storing them. The VFS API would
also need to indicate whether the file system supports them at all.
Again, this is not as easy as just stuffing these things into an
xattr and all of the above is outside the purview of NFSD. As we
don't have any Linux-native application use cases, I can't see
implementing support for them as a priority. But as always, patches
are welcome.
--
Chuck Lever
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.
--
Chuck Lever
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).
--
Jeff Layton <[email protected]>
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
On Sun, 2023-11-26 at 12:08 -0500, Chuck Lever wrote:
> 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.
>
>
Right. Samba has to emulate Windows semantics there, which are very
different around whether a dentry is visible to applications.
In principle, you could add a STATX_ATTR_HIDDEN flag for this, and leave
it up to the filesystem as to whether it should be set. Then if you were
exporting something like NTFS you could pass it through properly. I
don't see that as terribly useful though.
--
Jeff Layton <[email protected]>
On Sat, 25 Nov 2023 at 15:52, Jeff Layton <[email protected]> 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 <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On Thu, 2023-11-30 at 11:28 +0100, Cedric Blancher wrote:
> On Sat, 25 Nov 2023 at 15:52, Jeff Layton <[email protected]> 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.
Those are some big assumptions.
With #1, we generally don't do this sort of hacky carveout of user
xattrs in nfsd. That sort of thing is fine for a NFS appliance with a
hidden backend filesystem, but ours is a general-purpose server that
serves filesystems that may be locally accessible. We can't know whether
it's safe to use _any_ xattr on any given generic inode.
#2 is not even possible: Consider that we may need to satisfy a GETATTR
request after the server has rebooted. In that case, we may only have
the filehandle for the inode, and may not know any of its filenames yet.
The bottom line is that visibility in Unix/Linux is a property of the
_dentry_, but GETATTR is done against an inode which can be connected to
multiple dentries (some visible and some not). This is different from
Windows where it is a per-inode property (and hardlinks are mostly never
used).
I don't believe we'll ever be able to properly support this flag since
it conceptually just doesn't map onto the Linux filesystem.
--
Jeff Layton <[email protected]>