LInux NFSv4.1 client and server- case insensitive filesystems supported?

LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

Good evening!

Does the Linux NFSv4.1 client and server support case insensitive
filesystems, e.g. exported FAT or NTFS?

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

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Wed, 4 Jun 2025 at 19:58, Cedric Blancher <cedric.blancher@gmail.com> wrote:
>
> Good evening!
>
> Does the Linux NFSv4.1 client and server support case insensitive
> filesystems, e.g. exported FAT or NTFS?

Just found this in Linux kernel fs/nfsd/nfs4xdr.

        if (bmval0 & FATTR4_WORD0_CASE_INSENSITIVE) {
               p = xdr_reserve_space(xdr, 4);
               if (!p)
                       goto out_resource;
               *p++ = cpu_to_be32(0);
       }
       if (bmval0 & FATTR4_WORD0_CASE_PRESERVING) {
               p = xdr_reserve_space(xdr, 4);
               if (!p)
                       goto out_resource;
               *p++ = cpu_to_be32(1);
       }

How did this pass code review, ever?

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

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 6/4/25 2:52 PM, Cedric Blancher wrote:
> On Wed, 4 Jun 2025 at 19:58, Cedric Blancher <cedric.blancher@gmail.com> wrote:
>>
>> Good evening!
>>
>> Does the Linux NFSv4.1 client and server support case insensitive
>> filesystems, e.g. exported FAT or NTFS?
> 
> Just found this in Linux kernel fs/nfsd/nfs4xdr.
> 
>         if (bmval0 & FATTR4_WORD0_CASE_INSENSITIVE) {
>                p = xdr_reserve_space(xdr, 4);
>                if (!p)
>                        goto out_resource;
>                *p++ = cpu_to_be32(0);
>        }
>        if (bmval0 & FATTR4_WORD0_CASE_PRESERVING) {
>                p = xdr_reserve_space(xdr, 4);
>                if (!p)
>                        goto out_resource;
>                *p++ = cpu_to_be32(1);
>        }
> 
> How did this pass code review, ever?

Hi Cedric-

I presume what you are complaining about is that when these attributes
are queried, NFSD returns fixed values rather than interrogating the
file system on which the target object resides.

Until very recently, the Linux dentry cache supported only case-
sensitive file name lookups, and all of the file systems that NFSD is
regularly tested with are case-preserving.

In that light, this code is entirely justified, and reflects very
similar existing behavior for NFSD's implementation of NFSv3 PATHCONF
(see nfsd3_proc_pathconf). Historically, on Linux, there is only one
possible correct answer for these settings.

My impression is that real case-insensitivity has been added to the
dentry cache in support of FAT on Android devices (or something like
that). That clears the path a bit for NFSD, but it needs to be
researched to see if that new support is adequate for NFS to use.

Recently, Roland poked me about NFSD support for case insensitivity.
Unfortunately that is not a simple topic. There are probably one or two
people on the mailing lists Cc'd here who can explore this with you so
we can understand exactly what behavior folks are looking for, and
determine whether it is feasible to support it in NFSD. Please keep the
discussion public because I'm sure there are multiple interested
parties and even more opinions.


-- 
Chuck Lever

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Theodore Ts'o]

On Sat, Jun 07, 2025 at 02:30:37PM -0400, Chuck Lever wrote:
> 
> My impression is that real case-insensitivity has been added to the
> dentry cache in support of FAT on Android devices (or something like
> that). That clears the path a bit for NFSD, but it needs to be
> researched to see if that new support is adequate for NFS to use.

Case insensitivty was added in Linux in 2019, with the primary coding
work being done by Gabriel Krisman Bertazi of Collabora, and design
work being done being done by Gabriel, Michael Halcrow, and myself.
(Michael Halcrow in particular was responsible for devising how to
make case-insensitivity work with filename encryption and indexed
directories.)

The initial file systems that had case-insensitivty implemented was
ext4 and f2fs.  The initial use cases was Android devices (which had
used this horible wrapfs stacking file system thing which was trivial
to deadlock under stress, and its original reason for existing was
bug-for-bug compatibility with FAT), and for Steam so that Windows
games could have their expected case insensitivity.  (Collabora's work
was underwritten by Steam.)

There is an interesting write-up about NFS and case-insensitivity in a
relatively recent Internet-Draft[1], dated 2025-May-16.  In this I-D,
it points out that one of the primary concerns is that if the client
caches negative lookups under one case (say, MaDNeSS), and then the
file is created using a different case (say "madness"), then the
negative dentry cache indicating that MaDNeSS does not exist needs to
be removed when "madness" is created.  I'm not sure how Linux's NFS
client handles negative dentries, since even without
case-insensitivity, a file name that previously didn't exist could
have subsequently been created by another client on a different host.
So does Linux's NFS client simply does not use negative dentries, or
does it have some kind of cache invalidation scheme when the directory
has a new mtime, or some such?

[1] https://www.ietf.org/id/draft-ietf-nfsv4-internationalization-12.html#name-handling-of-string-equivale

Anyway, case sensitivity is one of those "interesting" problems which
has caused many headaches, including a potential security issue, and a
botched attempt to fix that security issue interacting poorly with
some of the more subtle design requirements so that file systems can
use tree-indexed directory lookups, even with case-insensitivty file
names and encrypted directory entries.  So in general, unless you have
strong financial backing where someone is willing to pay $$$ to
address a business-critical use case, my personal advice is to stay
far, far, away.  And I say this as a someone (with apologies to Linus)
who was partially responsible for Linux having case insensitivty
lookups in the first place.  :-)

Cheers,

						- Ted

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Jeff Layton]

On Sat, 2025-06-07 at 22:39 +0000, Theodore Ts'o wrote:
> On Sat, Jun 07, 2025 at 02:30:37PM -0400, Chuck Lever wrote:
> > 
> > My impression is that real case-insensitivity has been added to the
> > dentry cache in support of FAT on Android devices (or something like
> > that). That clears the path a bit for NFSD, but it needs to be
> > researched to see if that new support is adequate for NFS to use.
> 
> Case insensitivty was added in Linux in 2019, with the primary coding
> work being done by Gabriel Krisman Bertazi of Collabora, and design
> work being done being done by Gabriel, Michael Halcrow, and myself.
> (Michael Halcrow in particular was responsible for devising how to
> make case-insensitivity work with filename encryption and indexed
> directories.)
> 
> The initial file systems that had case-insensitivty implemented was
> ext4 and f2fs.  The initial use cases was Android devices (which had
> used this horible wrapfs stacking file system thing which was trivial
> to deadlock under stress, and its original reason for existing was
> bug-for-bug compatibility with FAT), and for Steam so that Windows
> games could have their expected case insensitivity.  (Collabora's work
> was underwritten by Steam.)
> 
> There is an interesting write-up about NFS and case-insensitivity in a
> relatively recent Internet-Draft[1], dated 2025-May-16.  In this I-D,
> it points out that one of the primary concerns is that if the client
> caches negative lookups under one case (say, MaDNeSS), and then the
> file is created using a different case (say "madness"), then the
> negative dentry cache indicating that MaDNeSS does not exist needs to
> be removed when "madness" is created.  I'm not sure how Linux's NFS
> client handles negative dentries, since even without
> case-insensitivity, a file name that previously didn't exist could
> have subsequently been created by another client on a different host.
> So does Linux's NFS client simply does not use negative dentries, or
> does it have some kind of cache invalidation scheme when the directory
> has a new mtime, or some such?
> 

It's a little more complicated than that, but that's basically right:

When the attrs on the parent directory indicate that there has been a
change to it since a dentry was last revalidated, the client will
return <=0 to d_revalidate attempts on the dentry. That will make the
VFS re-drive a lookup instead of trusting the cache.


> [1] https://www.ietf.org/id/draft-ietf-nfsv4-internationalization-12.html#name-handling-of-string-equivale
> 
> Anyway, case sensitivity is one of those "interesting" problems which
> has caused many headaches, including a potential security issue, and a
> botched attempt to fix that security issue interacting poorly with
> some of the more subtle design requirements so that file systems can
> use tree-indexed directory lookups, even with case-insensitivty file
> names and encrypted directory entries.  So in general, unless you have
> strong financial backing where someone is willing to pay $$$ to
> address a business-critical use case, my personal advice is to stay
> far, far, away.  And I say this as a someone (with apologies to Linus)
> who was partially responsible for Linux having case insensitivty
> lookups in the first place.  :-)

-- 
Jeff Layton <jlayton@kernel.org>

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 6/7/25 6:39 PM, Theodore Ts'o wrote:
> On Sat, Jun 07, 2025 at 02:30:37PM -0400, Chuck Lever wrote:
>>
>> My impression is that real case-insensitivity has been added to the
>> dentry cache in support of FAT on Android devices (or something like
>> that). That clears the path a bit for NFSD, but it needs to be
>> researched to see if that new support is adequate for NFS to use.
> 
> Case insensitivty was added in Linux in 2019, with the primary coding
> work being done by Gabriel Krisman Bertazi of Collabora, and design
> work being done being done by Gabriel, Michael Halcrow, and myself.
> (Michael Halcrow in particular was responsible for devising how to
> make case-insensitivity work with filename encryption and indexed
> directories.)

For some reason I thought case-insensitivity support was merged more
recently than that. I recall it first appearing as a session at LSF in
Park City, but maybe that one was in 2018.


> There is an interesting write-up about NFS and case-insensitivity in a
> relatively recent Internet-Draft[1], dated 2025-May-16.  In this I-D,
> it points out that one of the primary concerns is that if the client
> caches negative lookups under one case (say, MaDNeSS), and then the
> file is created using a different case (say "madness"), then the
> negative dentry cache indicating that MaDNeSS does not exist needs to
> be removed when "madness" is created.  I'm not sure how Linux's NFS
> client handles negative dentries, since even without
> case-insensitivity, a file name that previously didn't exist could
> have subsequently been created by another client on a different host.
> So does Linux's NFS client simply does not use negative dentries, or
> does it have some kind of cache invalidation scheme when the directory
> has a new mtime, or some such?
> 
> [1] https://www.ietf.org/id/draft-ietf-nfsv4-internationalization-12.html#name-handling-of-string-equivale

nfs(5) describes the lookupcache= mount option. It controls how the
Linux NFS client caches positive and negative lookup results.


-- 
Chuck Lever

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Theodore Ts'o]

On Sun, Jun 08, 2025 at 12:29:30PM -0400, Chuck Lever wrote:
> 
> For some reason I thought case-insensitivity support was merged more
> recently than that. I recall it first appearing as a session at LSF in
> Park City, but maybe that one was in 2018.

commit b886ee3e778ec2ad43e276fd378ab492cf6819b7
Author: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Date:   Thu Apr 25 14:12:08 2019 -0400

    ext4: Support case-insensitive file name lookups

> nfs(5) describes the lookupcache= mount option. It controls how the
> Linux NFS client caches positive and negative lookup results.

Has anyone just tried it?  It might just work.  To create a
case-folded directory:

# mke2fs -Fq -t ext4 -O casefold /dev/vdc
# mount /dev/vdc /vdc
# mkdir /vdc/casefold
# chattr +F /vdc/casefold
# cp /etc/issue /vdc/casefold/MaDNeSS
# cat /vdc/casefold/madness

Then export the directory and mount it via NFS, and let us know how it
goes.  I'm currently on a cruise ship so it's a bit harder for me to
do the experiment myself.  :-)

						- Ted

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 6/8/25 4:52 PM, Theodore Ts'o wrote:
> On Sun, Jun 08, 2025 at 12:29:30PM -0400, Chuck Lever wrote:
>>
>> For some reason I thought case-insensitivity support was merged more
>> recently than that. I recall it first appearing as a session at LSF in
>> Park City, but maybe that one was in 2018.
> 
> commit b886ee3e778ec2ad43e276fd378ab492cf6819b7
> Author: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
> Date:   Thu Apr 25 14:12:08 2019 -0400
> 
>     ext4: Support case-insensitive file name lookups
> 
>> nfs(5) describes the lookupcache= mount option. It controls how the
>> Linux NFS client caches positive and negative lookup results.
> 
> Has anyone just tried it?  It might just work.  To create a
> case-folded directory:
> 
> # mke2fs -Fq -t ext4 -O casefold /dev/vdc
> # mount /dev/vdc /vdc
> # mkdir /vdc/casefold
> # chattr +F /vdc/casefold
> # cp /etc/issue /vdc/casefold/MaDNeSS
> # cat /vdc/casefold/madness
> 
> Then export the directory and mount it via NFS, and let us know how it
> goes.  I'm currently on a cruise ship so it's a bit harder for me to
> do the experiment myself.  :-)

NFSD currently asserts that all exported file systems are case-sensitive
and case-preserving (either via NFSv3 or NFSv4). There is very likely
some additional work necessary.

Ted, do you happen to know if there are any fstests that exercise case-
insensitive lookups? I would not regard that simple test as "job done!
put pencil down!" :-)


-- 
Chuck Lever

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Gabriel Krisman Bertazi]

Chuck Lever <chuck.lever@oracle.com> writes:

> On 6/8/25 4:52 PM, Theodore Ts'o wrote:
>> On Sun, Jun 08, 2025 at 12:29:30PM -0400, Chuck Lever wrote:
>>>
>>> For some reason I thought case-insensitivity support was merged more
>>> recently than that. I recall it first appearing as a session at LSF in
>>> Park City, but maybe that one was in 2018.

Hi Chuck,

The first LSF discussion on this implementation was Park City, 2018. It
was merged early 2019.

> Ted, do you happen to know if there are any fstests that exercise case-
> insensitive lookups? I would not regard that simple test as "job done!
> put pencil down!" :-)

generic/556 tests basic semantics and many corner cases of casefolded
lookups.

-- 
Gabriel Krisman Bertazi

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Theodore Ts'o]

On Sun, Jun 08, 2025 at 05:52:36PM -0400, Chuck Lever wrote:
> NFSD currently asserts that all exported file systems are case-sensitive
> and case-preserving (either via NFSv3 or NFSv4). There is very likely
> some additional work necessary.

If the underlying file system on the server side does do case
insensitive lookups, how badly would it confuse the NFS client if a
lookup of "MaDNeSS" and "maddness" both worked and returned the same
file, even though readdir(2) only showed the existence of "MaDNeSS"
--- despite the fact that the nfsd asserted that file system was
case-sensitive?

> Ted, do you happen to know if there are any fstests that exercise case-
> insensitive lookups? I would not regard that simple test as "job done!
> put pencil down!" :-)

There are.   See:

common/casefold
tests/f2fs/012
tests/generic/453
tests/generic/454
tests/generic/556

You'll need to make some adjustments in common/casefold for NFS,
though.  The tests also assume that case insensivity can be adjusted
on a per-directory basis, using chattr +F and chattr -F, and that
probably isn't going to port over to NFS, so you might need to adjust
the tests as well.

Note that some of these tests also are checking Unicode case-folding
rules, which is a bit different from the ASCII case-folding which FAT
implemented.  It also might be interesting/amsuing to see what happens
if you ran these tests where the NFS server was exporting, say, a
case-folded file system from a MacOS server, or a Windows NFS server,
and the client was running Linux NFS.  Or what might happen if you
tried to do the same thing using, say, CIFS.   :-)

Cheers,

       	       	    	 	     	- Ted

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 6/9/25 11:50 AM, Theodore Ts'o wrote:
> On Sun, Jun 08, 2025 at 05:52:36PM -0400, Chuck Lever wrote:
>> NFSD currently asserts that all exported file systems are case-sensitive
>> and case-preserving (either via NFSv3 or NFSv4). There is very likely
>> some additional work necessary.
> 
> If the underlying file system on the server side does do case
> insensitive lookups, how badly would it confuse the NFS client if a
> lookup of "MaDNeSS" and "maddness" both worked and returned the same
> file, even though readdir(2) only showed the existence of "MaDNeSS"
> --- despite the fact that the nfsd asserted that file system was
> case-sensitive?

IIRC the Linux NFS client used to cache READDIR results via the dcache.
It doesn't do that, these days. If the client mounted with
lookupcache=none, it might work OK?


>> Ted, do you happen to know if there are any fstests that exercise case-
>> insensitive lookups? I would not regard that simple test as "job done!
>> put pencil down!" :-)
> 
> There are.   See:
> 
> common/casefold
> tests/f2fs/012
> tests/generic/453
> tests/generic/454
> tests/generic/556
> 
> You'll need to make some adjustments in common/casefold for NFS,
> though.  The tests also assume that case insensivity can be adjusted
> on a per-directory basis, using chattr +F and chattr -F, and that
> probably isn't going to port over to NFS, so you might need to adjust
> the tests as well.

This is probably the more general concern:

- Both the NFSv3 and NFSv4 protocols mark a whole file system as either
  case sensitive or case insensitive.

- NFS protocols do not facilitate case-sensitivity to be be enabled or
  disabled from NFS clients.

It sounds like it would be difficult for NFS clients to make sense of
an exported extN file system that contained some case sensitive and some
case insensitive directories.


> Note that some of these tests also are checking Unicode case-folding
> rules, which is a bit different from the ASCII case-folding which FAT
> implemented.  It also might be interesting/amsuing to see what happens
> if you ran these tests where the NFS server was exporting, say, a
> case-folded file system from a MacOS server, or a Windows NFS server,
> and the client was running Linux NFS.  Or what might happen if you
> tried to do the same thing using, say, CIFS.   :-)

Re-exporting remote file systems is a massive jungle even on good days.

I think a narrower concern might be keeping lookup behavior consistent
between local accessors, NFS accessors, and accessors via SMB (Samba or
ksmbd). I admit I have no idea if that's possible.


-- 
Chuck Lever

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Christoph Hellwig]

On Sat, Jun 07, 2025 at 02:30:37PM -0400, Chuck Lever wrote:
> Until very recently, the Linux dentry cache supported only case-
> sensitive file name lookups, and all of the file systems that NFSD is
> regularly tested with are case-preserving.

Linux has supported case insensitive file system since 1992 when Werner
added the original msdos FAT support, i.e. it exists much longer than
the dcache or knfsd.

Specific support for dealing with case insensitive in the dcache instead
working around it was added in 2008 for the case insensitive XFS
directories in 2008:

commit 9403540c0653122ca34884a180439ddbfcbcb524
Author: Barry Naujok <bnaujok@sgi.com>
Date:   Wed May 21 16:50:46 2008 +1000

    dcache: Add case-insensitive support d_ci_add() routine

That being said no one ever intended any of these to be exported over
NFS, and I also question the sanity of anyone wanting to use case
insensitive file systems over NFS.

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 6/9/25 1:57 AM, Christoph Hellwig wrote:
> On Sat, Jun 07, 2025 at 02:30:37PM -0400, Chuck Lever wrote:
>> Until very recently, the Linux dentry cache supported only case-
>> sensitive file name lookups, and all of the file systems that NFSD is
>> regularly tested with are case-preserving.
> 
> Linux has supported case insensitive file system since 1992 when Werner
> added the original msdos FAT support, i.e. it exists much longer than
> the dcache or knfsd.
> 
> Specific support for dealing with case insensitive in the dcache instead
> working around it was added in 2008 for the case insensitive XFS
> directories in 2008:
> 
> commit 9403540c0653122ca34884a180439ddbfcbcb524
> Author: Barry Naujok <bnaujok@sgi.com>
> Date:   Wed May 21 16:50:46 2008 +1000
> 
>     dcache: Add case-insensitive support d_ci_add() routine

My memory must be quite faulty then. I remember there being significant
controversy at the Park City LSF around some patches adding support for
case insensitivity. But so be it -- I must not have paid terribly close
attention due to lack of oxygen.


> That being said no one ever intended any of these to be exported over
> NFS, and I also question the sanity of anyone wanting to use case
> insensitive file systems over NFS.

My sense is that case insensitivity for NFS exports is for Windows-based
clients and/or compatibility with Samba / SMB clients. But it does open
up a whole bunch of twisty little corner cases that I'm not terribly
anxious to bite off and chew on (See the i18n Internet Draft that Ted
cited earlier just as a start).

Perhaps if we can narrow down the requirements and deployment
environments, some limited form of case-insensitivity support for NFS
might start to make sense.

Does it, for example, make sense for NFSD to query the file system
on its case sensitivity when it prepares an NFSv3 PATHCONF response?
Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
of internationalized file names?


-- 
Chuck Lever

Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Christoph Hellwig]

On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
> > Date:   Wed May 21 16:50:46 2008 +1000
> > 
> >     dcache: Add case-insensitive support d_ci_add() routine
> 
> My memory must be quite faulty then. I remember there being significant
> controversy at the Park City LSF around some patches adding support for
> case insensitivity. But so be it -- I must not have paid terribly close
> attention due to lack of oxygen.

Well, that is when the ext4 CI code landed, which added the unicode
normalization, and with that another whole bunch of issues.

> > That being said no one ever intended any of these to be exported over
> > NFS, and I also question the sanity of anyone wanting to use case
> > insensitive file systems over NFS.
> 
> My sense is that case insensitivity for NFS exports is for Windows-based
> clients

I still question the sanity of anyone using a Windows NFS client in
general, but even more so on a case insensitive file system :)


> Does it, for example, make sense for NFSD to query the file system
> on its case sensitivity when it prepares an NFSv3 PATHCONF response?
> Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
> of internationalized file names?

Linus hates pathconf any anything like it with passion.  Altough we
basically got it now with statx by tacking it onto a fast path
interface instead, which he now obviously also hates.  But yes, nfsd
not beeing able to query lots of attributes, including actual important
ones is largely due to the lack of proper VFS interfaces.

NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
> > > Date:   Wed May 21 16:50:46 2008 +1000
> > >
> > >     dcache: Add case-insensitive support d_ci_add() routine
> >
> > My memory must be quite faulty then. I remember there being significant
> > controversy at the Park City LSF around some patches adding support for
> > case insensitivity. But so be it -- I must not have paid terribly close
> > attention due to lack of oxygen.
>
> Well, that is when the ext4 CI code landed, which added the unicode
> normalization, and with that another whole bunch of issues.

Well, no one likes the Han unification, and the mess the Unicode
consortium made from that,
But the Chinese are working on a replacement standard for Unicode, so
that will be a lot of FUN =:-)

> > > That being said no one ever intended any of these to be exported over
> > > NFS, and I also question the sanity of anyone wanting to use case
> > > insensitive file systems over NFS.
> >
> > My sense is that case insensitivity for NFS exports is for Windows-based
> > clients
>
> I still question the sanity of anyone using a Windows NFS client in
> general, but even more so on a case insensitive file system :)

Well, if you want one and the same homedir on both Linux and Windows,
then you have the option between the SMB/CIFS and the Windows NFSv4.2
driver (I'm not counting the Windows NFSv3 driver due lack of ACL
support).
Both, as of September 2025, work fine for us for production usage.

> > Does it, for example, make sense for NFSD to query the file system
> > on its case sensitivity when it prepares an NFSv3 PATHCONF response?
> > Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
> > of internationalized file names?
>
> Linus hates pathconf any anything like it with passion.  Altough we
> basically got it now with statx by tacking it onto a fast path
> interface instead, which he now obviously also hates.  But yes, nfsd
> not beeing able to query lots of attributes, including actual important
> ones is largely due to the lack of proper VFS interfaces.

What does Linus recommend as an alternative to pathconf()?

Also, AGAIN the question:
Due lack of a VFS interface and the urgend use case of needing to
export a case-insensitive filesystem via NFSv4.x, could we please get
two /etc/exports options, one setting the case-insensitive boolean
(true, false, get-default-from-fs) and one for case-preserving (true,
false, get-default-from-fs)?

So far LInux nfsd does the WRONG thing here, and exports even
case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
server does it correctly.

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

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Tue, 9 Sept 2025 at 18:06, Cedric Blancher <cedric.blancher@gmail.com> wrote:
>
> On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
> > > > Date:   Wed May 21 16:50:46 2008 +1000
> > > >
> > > >     dcache: Add case-insensitive support d_ci_add() routine
> > >
> > > My memory must be quite faulty then. I remember there being significant
> > > controversy at the Park City LSF around some patches adding support for
> > > case insensitivity. But so be it -- I must not have paid terribly close
> > > attention due to lack of oxygen.
> >
> > Well, that is when the ext4 CI code landed, which added the unicode
> > normalization, and with that another whole bunch of issues.
>
> Well, no one likes the Han unification, and the mess the Unicode
> consortium made from that,
> But the Chinese are working on a replacement standard for Unicode, so
> that will be a lot of FUN =:-)
>
> > > > That being said no one ever intended any of these to be exported over
> > > > NFS, and I also question the sanity of anyone wanting to use case
> > > > insensitive file systems over NFS.
> > >
> > > My sense is that case insensitivity for NFS exports is for Windows-based
> > > clients
> >
> > I still question the sanity of anyone using a Windows NFS client in
> > general, but even more so on a case insensitive file system :)
>
> Well, if you want one and the same homedir on both Linux and Windows,
> then you have the option between the SMB/CIFS and the Windows NFSv4.2
> driver (I'm not counting the Windows NFSv3 driver due lack of ACL
> support).
> Both, as of September 2025, work fine for us for production usage.
>
> > > Does it, for example, make sense for NFSD to query the file system
> > > on its case sensitivity when it prepares an NFSv3 PATHCONF response?
> > > Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
> > > of internationalized file names?
> >
> > Linus hates pathconf any anything like it with passion.  Altough we
> > basically got it now with statx by tacking it onto a fast path
> > interface instead, which he now obviously also hates.  But yes, nfsd
> > not beeing able to query lots of attributes, including actual important
> > ones is largely due to the lack of proper VFS interfaces.
>
> What does Linus recommend as an alternative to pathconf()?
>
> Also, AGAIN the question:
> Due lack of a VFS interface and the urgend use case of needing to
> export a case-insensitive filesystem via NFSv4.x,

Just to clarify one of the use cases: If your Windows home dir is on
NFSv4, and try to install software like Chrome, Firefox, VMware as
user in your home dir, then you have a very good chance that all your
DLL files are spelled mixed case, but lookups for the DLLs come in as
either totally uppercase, or all lowercase. Sometimes all lowercase,
except the ".DLL" part.

If the NFSv4 attribute case-insensitive would be set correctly by
Linux nfsd all would be fine, but if not then the software will not
work. Unless you do what Microsoft support suggests: Please use the
Windows NFSv4.1 server, then all-is-fine(TM)!

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

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 9/9/25 12:06 PM, Cedric Blancher wrote:
> Due lack of a VFS interface and the urgend use case of needing to
> export a case-insensitive filesystem via NFSv4.x, could we please get
> two /etc/exports options, one setting the case-insensitive boolean
> (true, false, get-default-from-fs) and one for case-preserving (true,
> false, get-default-from-fs)?
> 
> So far LInux nfsd does the WRONG thing here, and exports even
> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> server does it correctly.

Hi Cedric,

Can you send a pointer to some documentation for the Windows NFSv4.1
implementation of this feature?


-- 
Chuck Lever

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Tue, 9 Sept 2025 at 18:12, Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > Due lack of a VFS interface and the urgend use case of needing to
> > export a case-insensitive filesystem via NFSv4.x, could we please get
> > two /etc/exports options, one setting the case-insensitive boolean
> > (true, false, get-default-from-fs) and one for case-preserving (true,
> > false, get-default-from-fs)?
> >
> > So far LInux nfsd does the WRONG thing here, and exports even
> > case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> > server does it correctly.
>
> Hi Cedric,
>
> Can you send a pointer to some documentation for the Windows NFSv4.1
> implementation of this feature?

That is just ON by default for the Windows NFSv4.1 server if you
export NTFS, and OFF by default for DVDs.
We never had to change it.

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nfsadmin
explains a bit of it, but for Windows Server 2022 and 2025 it's a bit
different. Part of the more interesting docs are behind a
paywall/Microsoft login.

FYI like NTFS, you can pass a translation file, which can be used to
do the codepoint mappings between uppercase and lowercase.

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

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 9/9/25 12:33 PM, Cedric Blancher wrote:
> On Tue, 9 Sept 2025 at 18:12, Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>> On 9/9/25 12:06 PM, Cedric Blancher wrote:
>>> Due lack of a VFS interface and the urgend use case of needing to
>>> export a case-insensitive filesystem via NFSv4.x, could we please get
>>> two /etc/exports options, one setting the case-insensitive boolean
>>> (true, false, get-default-from-fs) and one for case-preserving (true,
>>> false, get-default-from-fs)?
>>>
>>> So far LInux nfsd does the WRONG thing here, and exports even
>>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
>>> server does it correctly.

As always, I encourage you to, first, prototype in NFSD the hard-coding
of these settings as returned to NFS clients to see if that does what
you really need with Linux-native file systems.


>> Hi Cedric,
>>
>> Can you send a pointer to some documentation for the Windows NFSv4.1
>> implementation of this feature?
> 
> That is just ON by default for the Windows NFSv4.1 server if you
> export NTFS, and OFF by default for DVDs.
> We never had to change it.
> 
> https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nfsadmin
> explains a bit of it, but for Windows Server 2022 and 2025 it's a bit
> different. Part of the more interesting docs are behind a
> paywall/Microsoft login.

The feature is comprised of these three configuration options:


translationfile=<file> - Specifies a file containing mapping information
for replacing characters in the names of files when moving them from
Windows-based to UNIX-based file systems. If file is not specified, then
file name character translation is disabled. If the value of
translationfile is changed, you must restart the server for the change
to take effect.

casesensitivelookups={yes|no} - Specifies whether directory lookups are
case sensitive (require exact matching of character case).
You must also disable Windows kernel case-insensitivity to support
case-sensitive file names. To support case-sensitivity, change the DWord
value of the registry key, HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager\kernel, to 0.

ntfscase={lower|upper|preserve} - Specifies whether the case of
characters in the names of files in the NTFS file system will be
returned in lowercase, uppercase, or in the form stored in the
directory. The default setting is preserve. This setting can't be
changed if casesensitivelookups is set to yes.


Sounds like there is more going on than just setting an export option. I
will need to hunt down a Microsoft NFS developer to find out how much
the shared file system is involved in handling internal filename
resolution. I'm at SDC next week, there should be one or two there.


-- 
Chuck Lever

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Roland Mainz]

On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > On Tue, 9 Sept 2025 at 18:12, Chuck Lever <chuck.lever@oracle.com> wrote:
> >>
> >> On 9/9/25 12:06 PM, Cedric Blancher wrote:
> >>> Due lack of a VFS interface and the urgend use case of needing to
> >>> export a case-insensitive filesystem via NFSv4.x, could we please get
> >>> two /etc/exports options, one setting the case-insensitive boolean
> >>> (true, false, get-default-from-fs) and one for case-preserving (true,
> >>> false, get-default-from-fs)?
> >>>
> >>> So far LInux nfsd does the WRONG thing here, and exports even
> >>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> >>> server does it correctly.
>
> As always, I encourage you to, first, prototype in NFSD the hard-coding
> of these settings as returned to NFS clients to see if that does what
> you really need with Linux-native file systems.

If Cedric wants just case-insensitive mounts for a Windows NFSv4
(Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then the
only thing needed is ext4fs or NTFS in case-insensitive mode, and that
the Linux NFSv4.1 server sets FATTR4_WORD0_CASE_INSENSITIVE==true and
FATTR4_WORD0_CASE_PRESERVING==true (for FAT
FATTR4_WORD0_CASE_PRESERVING==false). Only applications using ADS
(Alternate Data Streams) will not work, because the Linux NFS server
does not support "OPENATTR"&co ops.

If Cedric wants Windows home dirs:
This is not working with the Linux NFSv4.1 server, because it must support:
- FATTR4_WORD1_SYSTEM
- FATTR4_WORD0_ARCHIVE
- FATTR4_WORD0_HIDDEN
- Full ACL support, the current draft POSIX-ACLs in Linux NFSv4.1
server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the Windows
"New User" profile setup (and gets you a temporary profile in
C:\Users\*.temp+lots of warnings and a note to log out immediately
because your user profile dir has been "corrupted")

Windows home dirs with NFSv4 only work so far with the
Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS server
(not tested yet).

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Rick Macklem]

On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz <roland.mainz@nrubsig.org> wrote:
>
> On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> >
> > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever <chuck.lever@oracle.com> wrote:
> > >>
> > >> On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > >>> Due lack of a VFS interface and the urgend use case of needing to
> > >>> export a case-insensitive filesystem via NFSv4.x, could we please get
> > >>> two /etc/exports options, one setting the case-insensitive boolean
> > >>> (true, false, get-default-from-fs) and one for case-preserving (true,
> > >>> false, get-default-from-fs)?
> > >>>
> > >>> So far LInux nfsd does the WRONG thing here, and exports even
> > >>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> > >>> server does it correctly.
> >
> > As always, I encourage you to, first, prototype in NFSD the hard-coding
> > of these settings as returned to NFS clients to see if that does what
> > you really need with Linux-native file systems.
>
> If Cedric wants just case-insensitive mounts for a Windows NFSv4
> (Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then the
> only thing needed is ext4fs or NTFS in case-insensitive mode, and that
> the Linux NFSv4.1 server sets FATTR4_WORD0_CASE_INSENSITIVE==true and
> FATTR4_WORD0_CASE_PRESERVING==true (for FAT
> FATTR4_WORD0_CASE_PRESERVING==false). Only applications using ADS
> (Alternate Data Streams) will not work, because the Linux NFS server
> does not support "OPENATTR"&co ops.
>
> If Cedric wants Windows home dirs:
> This is not working with the Linux NFSv4.1 server, because it must support:
> - FATTR4_WORD1_SYSTEM
> - FATTR4_WORD0_ARCHIVE
> - FATTR4_WORD0_HIDDEN
> - Full ACL support, the current draft POSIX-ACLs in Linux NFSv4.1
> server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the Windows
> "New User" profile setup (and gets you a temporary profile in
> C:\Users\*.temp+lots of warnings and a note to log out immediately
> because your user profile dir has been "corrupted")
>
> Windows home dirs with NFSv4 only work so far with the
> Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS server
> (not tested yet).
I'll just note that the named attribute support (the windows client
folk like the name)
along with Hidden and System are in 15 only.
And Archive is not supported because it is listed as "deprecated" in the RFC.
(If this case really needs it, someone should try to get it "undeprecated" on
nfsv4@ietf.org. I could add Archive easily. All of these are for ZFS only.
ZFS also knows case insensitive, although I have not tried it.)

rick

>
> ----
>
> Bye,
> Roland
> --
>   __ .  . __
>  (o.\ \/ /.o) roland.mainz@nrubsig.org
>   \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
>   /O /==\ O\  TEL +49 641 3992797
>  (;O/ \/ \O;)
>

fattr4_archive "deprecated" ? Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Wed, 10 Sept 2025 at 15:38, Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz <roland.mainz@nrubsig.org> wrote:
> >
> > On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> > >
> > > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever <chuck.lever@oracle.com> wrote:
> > > >>
> > > >> On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > > >>> Due lack of a VFS interface and the urgend use case of needing to
> > > >>> export a case-insensitive filesystem via NFSv4.x, could we please get
> > > >>> two /etc/exports options, one setting the case-insensitive boolean
> > > >>> (true, false, get-default-from-fs) and one for case-preserving (true,
> > > >>> false, get-default-from-fs)?
> > > >>>
> > > >>> So far LInux nfsd does the WRONG thing here, and exports even
> > > >>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> > > >>> server does it correctly.
> > >
> > > As always, I encourage you to, first, prototype in NFSD the hard-coding
> > > of these settings as returned to NFS clients to see if that does what
> > > you really need with Linux-native file systems.
> >
> > If Cedric wants just case-insensitive mounts for a Windows NFSv4
> > (Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then the
> > only thing needed is ext4fs or NTFS in case-insensitive mode, and that
> > the Linux NFSv4.1 server sets FATTR4_WORD0_CASE_INSENSITIVE==true and
> > FATTR4_WORD0_CASE_PRESERVING==true (for FAT
> > FATTR4_WORD0_CASE_PRESERVING==false). Only applications using ADS
> > (Alternate Data Streams) will not work, because the Linux NFS server
> > does not support "OPENATTR"&co ops.
> >
> > If Cedric wants Windows home dirs:
> > This is not working with the Linux NFSv4.1 server, because it must support:
> > - FATTR4_WORD1_SYSTEM
> > - FATTR4_WORD0_ARCHIVE
> > - FATTR4_WORD0_HIDDEN
> > - Full ACL support, the current draft POSIX-ACLs in Linux NFSv4.1
> > server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the Windows
> > "New User" profile setup (and gets you a temporary profile in
> > C:\Users\*.temp+lots of warnings and a note to log out immediately
> > because your user profile dir has been "corrupted")
> >
> > Windows home dirs with NFSv4 only work so far with the
> > Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS server
> > (not tested yet).
> I'll just note that the named attribute support (the windows client
> folk like the name)
> along with Hidden and System are in 15 only.
> And Archive is not supported because it is listed as "deprecated" in the RFC.
> (If this case really needs it, someone should try to get it "undeprecated" on
> nfsv4@ietf.org. I could add Archive easily. All of these are for ZFS only.
> ZFS also knows case insensitive, although I have not tried it.)

Who (name!) had the idea to declare fattr4_archive as "deprecated"? It
was explicitly added for Windows and DOS compatibility in NFSv4, and
unlike Windows EAs (which are depreciated, and were superseded by
"named streams") the "archive" attribute is still in use.

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

Re: fattr4_archive "deprecated" ? Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Rick Macklem]

On Thu, Sep 11, 2025 at 1:08 AM Cedric Blancher
<cedric.blancher@gmail.com> wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca.
>
> On Wed, 10 Sept 2025 at 15:38, Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz <roland.mainz@nrubsig.org> wrote:
> > >
> > > On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> > > >
> > > > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever <chuck.lever@oracle.com> wrote:
> > > > >>
> > > > >> On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > > > >>> Due lack of a VFS interface and the urgend use case of needing to
> > > > >>> export a case-insensitive filesystem via NFSv4.x, could we please get
> > > > >>> two /etc/exports options, one setting the case-insensitive boolean
> > > > >>> (true, false, get-default-from-fs) and one for case-preserving (true,
> > > > >>> false, get-default-from-fs)?
> > > > >>>
> > > > >>> So far LInux nfsd does the WRONG thing here, and exports even
> > > > >>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> > > > >>> server does it correctly.
> > > >
> > > > As always, I encourage you to, first, prototype in NFSD the hard-coding
> > > > of these settings as returned to NFS clients to see if that does what
> > > > you really need with Linux-native file systems.
> > >
> > > If Cedric wants just case-insensitive mounts for a Windows NFSv4
> > > (Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then the
> > > only thing needed is ext4fs or NTFS in case-insensitive mode, and that
> > > the Linux NFSv4.1 server sets FATTR4_WORD0_CASE_INSENSITIVE==true and
> > > FATTR4_WORD0_CASE_PRESERVING==true (for FAT
> > > FATTR4_WORD0_CASE_PRESERVING==false). Only applications using ADS
> > > (Alternate Data Streams) will not work, because the Linux NFS server
> > > does not support "OPENATTR"&co ops.
> > >
> > > If Cedric wants Windows home dirs:
> > > This is not working with the Linux NFSv4.1 server, because it must support:
> > > - FATTR4_WORD1_SYSTEM
> > > - FATTR4_WORD0_ARCHIVE
> > > - FATTR4_WORD0_HIDDEN
> > > - Full ACL support, the current draft POSIX-ACLs in Linux NFSv4.1
> > > server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the Windows
> > > "New User" profile setup (and gets you a temporary profile in
> > > C:\Users\*.temp+lots of warnings and a note to log out immediately
> > > because your user profile dir has been "corrupted")
> > >
> > > Windows home dirs with NFSv4 only work so far with the
> > > Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS server
> > > (not tested yet).
> > I'll just note that the named attribute support (the windows client
> > folk like the name)
> > along with Hidden and System are in 15 only.
> > And Archive is not supported because it is listed as "deprecated" in the RFC.
> > (If this case really needs it, someone should try to get it "undeprecated" on
> > nfsv4@ietf.org. I could add Archive easily. All of these are for ZFS only.
> > ZFS also knows case insensitive, although I have not tried it.)
>
> Who (name!) had the idea to declare fattr4_archive as "deprecated"? It
> was explicitly added for Windows and DOS compatibility in NFSv4, and
> unlike Windows EAs (which are depreciated, and were superseded by
> "named streams") the "archive" attribute is still in use.
I have no idea who would have done this, but here is the snippet from
RFC5661 (which started being edited in 2005 and was published in 2010,
so it has been like this for a long time). The same words are in RFC8881
and currently in the RFC8881bis draft. Can this be changed?
I'd say yes, but it will take time and effort on someone's part.
Posting to nfsv4@ietf.org, noting that this attribute is needed
by the Windows client (and at least a suggestion that time_backup
is not a satisfactory replacement) would be a good start.

5.8.2.1.  Attribute 14: archive

   TRUE, if this file has been archived since the time of last
   modification (deprecated in favor of time_backup).

The problem has been a serious lack of Windows expertise in the NFSv4
working group. Long ago (20+ years) the Hummingbird developers were
actively involved (Hummingbird became Open Network Solutions, which
became a division of OpenText, if I recall it correctly).

But there has been no one with Windows expertise involved more recently.

My suggestion (I'll repeat it) is to have someone participate in the Bakeathon
testing events (the next one is in about one month and can be attended
remotely using a tailscale VPN). When someone tests at the event and
finds an issue, the server developers are there and can discussion what
it takes to fix it.

Also, participation on the nfsv4@ietf.org mailing list (some working group
members will not be reading this Linux list) and attendance at working
group meetings would help. (The working group meetings can
also be attended remotely and there is an automatic fee waiver for
remote attendance if you, like me, are not funded to do the work.)

With no involvement from people with Windows expertise, the testing
has become basically a bunch of servers being tested against by
various versions of the Linux client (with me being at outlier, testing
the FreeBSD client).

rick

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

Re: fattr4_archive "deprecated" ? Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Trond Myklebust]

On Thu, 2025-09-11 at 08:01 -0700, Rick Macklem wrote:
> On Thu, Sep 11, 2025 at 1:08 AM Cedric Blancher
> <cedric.blancher@gmail.com> wrote:
> > 
> > CAUTION: This email originated from outside of the University of
> > Guelph. Do not click links or open attachments unless you recognize
> > the sender and know the content is safe. If in doubt, forward
> > suspicious emails to IThelp@uoguelph.ca.
> > 
> > On Wed, 10 Sept 2025 at 15:38, Rick Macklem
> > <rick.macklem@gmail.com> wrote:
> > > 
> > > On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz
> > > <roland.mainz@nrubsig.org> wrote:
> > > > 
> > > > On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever
> > > > <chuck.lever@oracle.com> wrote:
> > > > > 
> > > > > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > > > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever
> > > > > > <chuck.lever@oracle.com> wrote:
> > > > > > > 
> > > > > > > On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > > > > > > > Due lack of a VFS interface and the urgend use case of
> > > > > > > > needing to
> > > > > > > > export a case-insensitive filesystem via NFSv4.x, could
> > > > > > > > we please get
> > > > > > > > two /etc/exports options, one setting the case-
> > > > > > > > insensitive boolean
> > > > > > > > (true, false, get-default-from-fs) and one for case-
> > > > > > > > preserving (true,
> > > > > > > > false, get-default-from-fs)?
> > > > > > > > 
> > > > > > > > So far LInux nfsd does the WRONG thing here, and
> > > > > > > > exports even
> > > > > > > > case-insensitive filesystems as case-sensitive. The
> > > > > > > > Windows NFSv4.1
> > > > > > > > server does it correctly.
> > > > > 
> > > > > As always, I encourage you to, first, prototype in NFSD the
> > > > > hard-coding
> > > > > of these settings as returned to NFS clients to see if that
> > > > > does what
> > > > > you really need with Linux-native file systems.
> > > > 
> > > > If Cedric wants just case-insensitive mounts for a Windows
> > > > NFSv4
> > > > (Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then
> > > > the
> > > > only thing needed is ext4fs or NTFS in case-insensitive mode,
> > > > and that
> > > > the Linux NFSv4.1 server sets
> > > > FATTR4_WORD0_CASE_INSENSITIVE==true and
> > > > FATTR4_WORD0_CASE_PRESERVING==true (for FAT
> > > > FATTR4_WORD0_CASE_PRESERVING==false). Only applications using
> > > > ADS
> > > > (Alternate Data Streams) will not work, because the Linux NFS
> > > > server
> > > > does not support "OPENATTR"&co ops.
> > > > 
> > > > If Cedric wants Windows home dirs:
> > > > This is not working with the Linux NFSv4.1 server, because it
> > > > must support:
> > > > - FATTR4_WORD1_SYSTEM
> > > > - FATTR4_WORD0_ARCHIVE
> > > > - FATTR4_WORD0_HIDDEN
> > > > - Full ACL support, the current draft POSIX-ACLs in Linux
> > > > NFSv4.1
> > > > server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the
> > > > Windows
> > > > "New User" profile setup (and gets you a temporary profile in
> > > > C:\Users\*.temp+lots of warnings and a note to log out
> > > > immediately
> > > > because your user profile dir has been "corrupted")
> > > > 
> > > > Windows home dirs with NFSv4 only work so far with the
> > > > Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS
> > > > server
> > > > (not tested yet).
> > > I'll just note that the named attribute support (the windows
> > > client
> > > folk like the name)
> > > along with Hidden and System are in 15 only.
> > > And Archive is not supported because it is listed as "deprecated"
> > > in the RFC.
> > > (If this case really needs it, someone should try to get it
> > > "undeprecated" on
> > > nfsv4@ietf.org. I could add Archive easily. All of these are for
> > > ZFS only.
> > > ZFS also knows case insensitive, although I have not tried it.)
> > 
> > Who (name!) had the idea to declare fattr4_archive as "deprecated"?
> > It
> > was explicitly added for Windows and DOS compatibility in NFSv4,
> > and
> > unlike Windows EAs (which are depreciated, and were superseded by
> > "named streams") the "archive" attribute is still in use.
> I have no idea who would have done this, but here is the snippet from
> RFC5661 (which started being edited in 2005 and was published in
> 2010,
> so it has been like this for a long time). The same words are in
> RFC8881
> and currently in the RFC8881bis draft. Can this be changed?
> I'd say yes, but it will take time and effort on someone's part.
> Posting to nfsv4@ietf.org, noting that this attribute is needed
> by the Windows client (and at least a suggestion that time_backup
> is not a satisfactory replacement) would be a good start.
> 
> 5.8.2.1.  Attribute 14: archive
> 
>    TRUE, if this file has been archived since the time of last
>    modification (deprecated in favor of time_backup).
> 
> The problem has been a serious lack of Windows expertise in the NFSv4
> working group. Long ago (20+ years) the Hummingbird developers were
> actively involved (Hummingbird became Open Network Solutions, which
> became a division of OpenText, if I recall it correctly).
> 
> But there has been no one with Windows expertise involved more
> recently.
> 
> My suggestion (I'll repeat it) is to have someone participate in the
> Bakeathon
> testing events (the next one is in about one month and can be
> attended
> remotely using a tailscale VPN). When someone tests at the event and
> finds an issue, the server developers are there and can discussion
> what
> it takes to fix it.
> 
> Also, participation on the nfsv4@ietf.org mailing list (some working
> group
> members will not be reading this Linux list) and attendance at
> working
> group meetings would help. (The working group meetings can
> also be attended remotely and there is an automatic fee waiver for
> remote attendance if you, like me, are not funded to do the work.)
> 
> With no involvement from people with Windows expertise, the testing
> has become basically a bunch of servers being tested against by
> various versions of the Linux client (with me being at outlier,
> testing
> the FreeBSD client).

As stated in the line you quote, it is listed as being deprecated in
favour of the backup time because the latter provides a superset of the
same functionality: by comparing the value of the backup time to the
value of the mtime, you can determine the value of the archive bit (it
is set if the backup time is newer than the mtime).

In addition, the backup time also tells you exactly when the file was
last backed up.

So no, this is not about people who don't understand Windows. It's
about repackaging the same functionality in a way that is more useful
to people who understand backups.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com

Re: fattr4_archive "deprecated" ? Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Thu, 11 Sept 2025 at 17:26, Trond Myklebust <trondmy@kernel.org> wrote:
>
> On Thu, 2025-09-11 at 08:01 -0700, Rick Macklem wrote:
> > On Thu, Sep 11, 2025 at 1:08 AM Cedric Blancher
> > <cedric.blancher@gmail.com> wrote:
> > >
> > > CAUTION: This email originated from outside of the University of
> > > Guelph. Do not click links or open attachments unless you recognize
> > > the sender and know the content is safe. If in doubt, forward
> > > suspicious emails to IThelp@uoguelph.ca.
> > >
> > > On Wed, 10 Sept 2025 at 15:38, Rick Macklem
> > > <rick.macklem@gmail.com> wrote:
> > > >
> > > > On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz
> > > > <roland.mainz@nrubsig.org> wrote:
> > > > >
> > > > > On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever
> > > > > <chuck.lever@oracle.com> wrote:
> > > > > >
> > > > > > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > > > > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever
> > > > > > > <chuck.lever@oracle.com> wrote:
> > > > > > > >
> > > > > > > > On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > > > > > > > > Due lack of a VFS interface and the urgend use case of
> > > > > > > > > needing to
> > > > > > > > > export a case-insensitive filesystem via NFSv4.x, could
> > > > > > > > > we please get
> > > > > > > > > two /etc/exports options, one setting the case-
> > > > > > > > > insensitive boolean
> > > > > > > > > (true, false, get-default-from-fs) and one for case-
> > > > > > > > > preserving (true,
> > > > > > > > > false, get-default-from-fs)?
> > > > > > > > >
> > > > > > > > > So far LInux nfsd does the WRONG thing here, and
> > > > > > > > > exports even
> > > > > > > > > case-insensitive filesystems as case-sensitive. The
> > > > > > > > > Windows NFSv4.1
> > > > > > > > > server does it correctly.
> > > > > >
> > > > > > As always, I encourage you to, first, prototype in NFSD the
> > > > > > hard-coding
> > > > > > of these settings as returned to NFS clients to see if that
> > > > > > does what
> > > > > > you really need with Linux-native file systems.
> > > > >
> > > > > If Cedric wants just case-insensitive mounts for a Windows
> > > > > NFSv4
> > > > > (Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then
> > > > > the
> > > > > only thing needed is ext4fs or NTFS in case-insensitive mode,
> > > > > and that
> > > > > the Linux NFSv4.1 server sets
> > > > > FATTR4_WORD0_CASE_INSENSITIVE==true and
> > > > > FATTR4_WORD0_CASE_PRESERVING==true (for FAT
> > > > > FATTR4_WORD0_CASE_PRESERVING==false). Only applications using
> > > > > ADS
> > > > > (Alternate Data Streams) will not work, because the Linux NFS
> > > > > server
> > > > > does not support "OPENATTR"&co ops.
> > > > >
> > > > > If Cedric wants Windows home dirs:
> > > > > This is not working with the Linux NFSv4.1 server, because it
> > > > > must support:
> > > > > - FATTR4_WORD1_SYSTEM
> > > > > - FATTR4_WORD0_ARCHIVE
> > > > > - FATTR4_WORD0_HIDDEN
> > > > > - Full ACL support, the current draft POSIX-ACLs in Linux
> > > > > NFSv4.1
> > > > > server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the
> > > > > Windows
> > > > > "New User" profile setup (and gets you a temporary profile in
> > > > > C:\Users\*.temp+lots of warnings and a note to log out
> > > > > immediately
> > > > > because your user profile dir has been "corrupted")
> > > > >
> > > > > Windows home dirs with NFSv4 only work so far with the
> > > > > Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS
> > > > > server
> > > > > (not tested yet).
> > > > I'll just note that the named attribute support (the windows
> > > > client
> > > > folk like the name)
> > > > along with Hidden and System are in 15 only.
> > > > And Archive is not supported because it is listed as "deprecated"
> > > > in the RFC.
> > > > (If this case really needs it, someone should try to get it
> > > > "undeprecated" on
> > > > nfsv4@ietf.org. I could add Archive easily. All of these are for
> > > > ZFS only.
> > > > ZFS also knows case insensitive, although I have not tried it.)
> > >
> > > Who (name!) had the idea to declare fattr4_archive as "deprecated"?
> > > It
> > > was explicitly added for Windows and DOS compatibility in NFSv4,
> > > and
> > > unlike Windows EAs (which are depreciated, and were superseded by
> > > "named streams") the "archive" attribute is still in use.
> > I have no idea who would have done this, but here is the snippet from
> > RFC5661 (which started being edited in 2005 and was published in
> > 2010,
> > so it has been like this for a long time). The same words are in
> > RFC8881
> > and currently in the RFC8881bis draft. Can this be changed?
> > I'd say yes, but it will take time and effort on someone's part.
> > Posting to nfsv4@ietf.org, noting that this attribute is needed
> > by the Windows client (and at least a suggestion that time_backup
> > is not a satisfactory replacement) would be a good start.
> >
> > 5.8.2.1.  Attribute 14: archive
> >
> >    TRUE, if this file has been archived since the time of last
> >    modification (deprecated in favor of time_backup).
> >
> > The problem has been a serious lack of Windows expertise in the NFSv4
> > working group. Long ago (20+ years) the Hummingbird developers were
> > actively involved (Hummingbird became Open Network Solutions, which
> > became a division of OpenText, if I recall it correctly).
> >
> > But there has been no one with Windows expertise involved more
> > recently.
> >
> > My suggestion (I'll repeat it) is to have someone participate in the
> > Bakeathon
> > testing events (the next one is in about one month and can be
> > attended
> > remotely using a tailscale VPN). When someone tests at the event and
> > finds an issue, the server developers are there and can discussion
> > what
> > it takes to fix it.
> >
> > Also, participation on the nfsv4@ietf.org mailing list (some working
> > group
> > members will not be reading this Linux list) and attendance at
> > working
> > group meetings would help. (The working group meetings can
> > also be attended remotely and there is an automatic fee waiver for
> > remote attendance if you, like me, are not funded to do the work.)
> >
> > With no involvement from people with Windows expertise, the testing
> > has become basically a bunch of servers being tested against by
> > various versions of the Linux client (with me being at outlier,
> > testing
> > the FreeBSD client).
>
> As stated in the line you quote, it is listed as being deprecated in
> favour of the backup time because the latter provides a superset of the
> same functionality: by comparing the value of the backup time to the
> value of the mtime, you can determine the value of the archive bit (it
> is set if the backup time is newer than the mtime).
>
> In addition, the backup time also tells you exactly when the file was
> last backed up.
>
> So no, this is not about people who don't understand Windows. It's
> about repackaging the same functionality in a way that is more useful
> to people who understand backups.

fattr4_archive was added long ago by SUN and CITI for NFS4, for
feature parity with SMB, and to accurately map Windows and DOS
features (the "A" flag). It cannot be replaced by a timestamp, because
neither Windows nor DOS have a "backup timestamp", except in
specialised software.
It might have made sense from a Linux point of view, but that
literally disables the "archive" flag for Windows and DOS, with
chaotic consequences. An additional "backup timestamp" is nice, but in
this specific case it damages a platform.

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

Re: fattr4_archive "deprecated" ? Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Thu, 11 Sept 2025 at 17:33, Cedric Blancher
<cedric.blancher@gmail.com> wrote:
>
> On Thu, 11 Sept 2025 at 17:26, Trond Myklebust <trondmy@kernel.org> wrote:
> >
> > On Thu, 2025-09-11 at 08:01 -0700, Rick Macklem wrote:
> > > On Thu, Sep 11, 2025 at 1:08 AM Cedric Blancher
> > > <cedric.blancher@gmail.com> wrote:
> > > >
> > > > CAUTION: This email originated from outside of the University of
> > > > Guelph. Do not click links or open attachments unless you recognize
> > > > the sender and know the content is safe. If in doubt, forward
> > > > suspicious emails to IThelp@uoguelph.ca.
> > > >
> > > > On Wed, 10 Sept 2025 at 15:38, Rick Macklem
> > > > <rick.macklem@gmail.com> wrote:
> > > > >
> > > > > On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz
> > > > > <roland.mainz@nrubsig.org> wrote:
> > > > > >
> > > > > > On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever
> > > > > > <chuck.lever@oracle.com> wrote:
> > > > > > >
> > > > > > > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > > > > > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever
> > > > > > > > <chuck.lever@oracle.com> wrote:
> > > > > > > > >
> > > > > > > > > On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > > > > > > > > > Due lack of a VFS interface and the urgend use case of
> > > > > > > > > > needing to
> > > > > > > > > > export a case-insensitive filesystem via NFSv4.x, could
> > > > > > > > > > we please get
> > > > > > > > > > two /etc/exports options, one setting the case-
> > > > > > > > > > insensitive boolean
> > > > > > > > > > (true, false, get-default-from-fs) and one for case-
> > > > > > > > > > preserving (true,
> > > > > > > > > > false, get-default-from-fs)?
> > > > > > > > > >
> > > > > > > > > > So far LInux nfsd does the WRONG thing here, and
> > > > > > > > > > exports even
> > > > > > > > > > case-insensitive filesystems as case-sensitive. The
> > > > > > > > > > Windows NFSv4.1
> > > > > > > > > > server does it correctly.
> > > > > > >
> > > > > > > As always, I encourage you to, first, prototype in NFSD the
> > > > > > > hard-coding
> > > > > > > of these settings as returned to NFS clients to see if that
> > > > > > > does what
> > > > > > > you really need with Linux-native file systems.
> > > > > >
> > > > > > If Cedric wants just case-insensitive mounts for a Windows
> > > > > > NFSv4
> > > > > > (Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then
> > > > > > the
> > > > > > only thing needed is ext4fs or NTFS in case-insensitive mode,
> > > > > > and that
> > > > > > the Linux NFSv4.1 server sets
> > > > > > FATTR4_WORD0_CASE_INSENSITIVE==true and
> > > > > > FATTR4_WORD0_CASE_PRESERVING==true (for FAT
> > > > > > FATTR4_WORD0_CASE_PRESERVING==false). Only applications using
> > > > > > ADS
> > > > > > (Alternate Data Streams) will not work, because the Linux NFS
> > > > > > server
> > > > > > does not support "OPENATTR"&co ops.
> > > > > >
> > > > > > If Cedric wants Windows home dirs:
> > > > > > This is not working with the Linux NFSv4.1 server, because it
> > > > > > must support:
> > > > > > - FATTR4_WORD1_SYSTEM
> > > > > > - FATTR4_WORD0_ARCHIVE
> > > > > > - FATTR4_WORD0_HIDDEN
> > > > > > - Full ACL support, the current draft POSIX-ACLs in Linux
> > > > > > NFSv4.1
> > > > > > server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the
> > > > > > Windows
> > > > > > "New User" profile setup (and gets you a temporary profile in
> > > > > > C:\Users\*.temp+lots of warnings and a note to log out
> > > > > > immediately
> > > > > > because your user profile dir has been "corrupted")
> > > > > >
> > > > > > Windows home dirs with NFSv4 only work so far with the
> > > > > > Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS
> > > > > > server
> > > > > > (not tested yet).
> > > > > I'll just note that the named attribute support (the windows
> > > > > client
> > > > > folk like the name)
> > > > > along with Hidden and System are in 15 only.
> > > > > And Archive is not supported because it is listed as "deprecated"
> > > > > in the RFC.
> > > > > (If this case really needs it, someone should try to get it
> > > > > "undeprecated" on
> > > > > nfsv4@ietf.org. I could add Archive easily. All of these are for
> > > > > ZFS only.
> > > > > ZFS also knows case insensitive, although I have not tried it.)
> > > >
> > > > Who (name!) had the idea to declare fattr4_archive as "deprecated"?
> > > > It
> > > > was explicitly added for Windows and DOS compatibility in NFSv4,
> > > > and
> > > > unlike Windows EAs (which are depreciated, and were superseded by
> > > > "named streams") the "archive" attribute is still in use.
> > > I have no idea who would have done this, but here is the snippet from
> > > RFC5661 (which started being edited in 2005 and was published in
> > > 2010,
> > > so it has been like this for a long time). The same words are in
> > > RFC8881
> > > and currently in the RFC8881bis draft. Can this be changed?
> > > I'd say yes, but it will take time and effort on someone's part.
> > > Posting to nfsv4@ietf.org, noting that this attribute is needed
> > > by the Windows client (and at least a suggestion that time_backup
> > > is not a satisfactory replacement) would be a good start.
> > >
> > > 5.8.2.1.  Attribute 14: archive
> > >
> > >    TRUE, if this file has been archived since the time of last
> > >    modification (deprecated in favor of time_backup).
> > >
> > > The problem has been a serious lack of Windows expertise in the NFSv4
> > > working group. Long ago (20+ years) the Hummingbird developers were
> > > actively involved (Hummingbird became Open Network Solutions, which
> > > became a division of OpenText, if I recall it correctly).
> > >
> > > But there has been no one with Windows expertise involved more
> > > recently.
> > >
> > > My suggestion (I'll repeat it) is to have someone participate in the
> > > Bakeathon
> > > testing events (the next one is in about one month and can be
> > > attended
> > > remotely using a tailscale VPN). When someone tests at the event and
> > > finds an issue, the server developers are there and can discussion
> > > what
> > > it takes to fix it.
> > >
> > > Also, participation on the nfsv4@ietf.org mailing list (some working
> > > group
> > > members will not be reading this Linux list) and attendance at
> > > working
> > > group meetings would help. (The working group meetings can
> > > also be attended remotely and there is an automatic fee waiver for
> > > remote attendance if you, like me, are not funded to do the work.)
> > >
> > > With no involvement from people with Windows expertise, the testing
> > > has become basically a bunch of servers being tested against by
> > > various versions of the Linux client (with me being at outlier,
> > > testing
> > > the FreeBSD client).
> >
> > As stated in the line you quote, it is listed as being deprecated in
> > favour of the backup time because the latter provides a superset of the
> > same functionality: by comparing the value of the backup time to the
> > value of the mtime, you can determine the value of the archive bit (it
> > is set if the backup time is newer than the mtime).
> >
> > In addition, the backup time also tells you exactly when the file was
> > last backed up.
> >
> > So no, this is not about people who don't understand Windows. It's
> > about repackaging the same functionality in a way that is more useful
> > to people who understand backups.
>
> fattr4_archive was added long ago by SUN and CITI for NFS4, for
> feature parity with SMB, and to accurately map Windows and DOS
> features (the "A" flag). It cannot be replaced by a timestamp, because
> neither Windows nor DOS have a "backup timestamp", except in
> specialised software.
> It might have made sense from a Linux point of view, but that
> literally disables the "archive" flag for Windows and DOS, with
> chaotic consequences. An additional "backup timestamp" is nice, but in
> this specific case it damages a platform.

I hit <SEND> too early. The backup timestamp is fine, just declaring
"fattr4_archive" is premature, unless Windows as a platform is
considered no longer supported by IETF. But then NFS should be renamed
to LFS (linux file system)

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

Re: fattr4_archive "deprecated" ? Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Thu, 11 Sept 2025 at 17:36, Cedric Blancher
<cedric.blancher@gmail.com> wrote:
>
> On Thu, 11 Sept 2025 at 17:33, Cedric Blancher
> <cedric.blancher@gmail.com> wrote:
> >
> > On Thu, 11 Sept 2025 at 17:26, Trond Myklebust <trondmy@kernel.org> wrote:
> > >
> > > On Thu, 2025-09-11 at 08:01 -0700, Rick Macklem wrote:
> > > > On Thu, Sep 11, 2025 at 1:08 AM Cedric Blancher
> > > > <cedric.blancher@gmail.com> wrote:
> > > > >
> > > > > CAUTION: This email originated from outside of the University of
> > > > > Guelph. Do not click links or open attachments unless you recognize
> > > > > the sender and know the content is safe. If in doubt, forward
> > > > > suspicious emails to IThelp@uoguelph.ca.
> > > > >
> > > > > On Wed, 10 Sept 2025 at 15:38, Rick Macklem
> > > > > <rick.macklem@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz
> > > > > > <roland.mainz@nrubsig.org> wrote:
> > > > > > >
> > > > > > > On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever
> > > > > > > <chuck.lever@oracle.com> wrote:
> > > > > > > >
> > > > > > > > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > > > > > > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever
> > > > > > > > > <chuck.lever@oracle.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On 9/9/25 12:06 PM, Cedric Blancher wrote:
> > > > > > > > > > > Due lack of a VFS interface and the urgend use case of
> > > > > > > > > > > needing to
> > > > > > > > > > > export a case-insensitive filesystem via NFSv4.x, could
> > > > > > > > > > > we please get
> > > > > > > > > > > two /etc/exports options, one setting the case-
> > > > > > > > > > > insensitive boolean
> > > > > > > > > > > (true, false, get-default-from-fs) and one for case-
> > > > > > > > > > > preserving (true,
> > > > > > > > > > > false, get-default-from-fs)?
> > > > > > > > > > >
> > > > > > > > > > > So far LInux nfsd does the WRONG thing here, and
> > > > > > > > > > > exports even
> > > > > > > > > > > case-insensitive filesystems as case-sensitive. The
> > > > > > > > > > > Windows NFSv4.1
> > > > > > > > > > > server does it correctly.
> > > > > > > >
> > > > > > > > As always, I encourage you to, first, prototype in NFSD the
> > > > > > > > hard-coding
> > > > > > > > of these settings as returned to NFS clients to see if that
> > > > > > > > does what
> > > > > > > > you really need with Linux-native file systems.
> > > > > > >
> > > > > > > If Cedric wants just case-insensitive mounts for a Windows
> > > > > > > NFSv4
> > > > > > > (Exceed, OpenText, ms-nfs41-client, ms-nfs42-client, ...), then
> > > > > > > the
> > > > > > > only thing needed is ext4fs or NTFS in case-insensitive mode,
> > > > > > > and that
> > > > > > > the Linux NFSv4.1 server sets
> > > > > > > FATTR4_WORD0_CASE_INSENSITIVE==true and
> > > > > > > FATTR4_WORD0_CASE_PRESERVING==true (for FAT
> > > > > > > FATTR4_WORD0_CASE_PRESERVING==false). Only applications using
> > > > > > > ADS
> > > > > > > (Alternate Data Streams) will not work, because the Linux NFS
> > > > > > > server
> > > > > > > does not support "OPENATTR"&co ops.
> > > > > > >
> > > > > > > If Cedric wants Windows home dirs:
> > > > > > > This is not working with the Linux NFSv4.1 server, because it
> > > > > > > must support:
> > > > > > > - FATTR4_WORD1_SYSTEM
> > > > > > > - FATTR4_WORD0_ARCHIVE
> > > > > > > - FATTR4_WORD0_HIDDEN
> > > > > > > - Full ACL support, the current draft POSIX-ACLs in Linux
> > > > > > > NFSv4.1
> > > > > > > server&&{ ext4fs, btrfs, xfs etc. } causes malfunctions in the
> > > > > > > Windows
> > > > > > > "New User" profile setup (and gets you a temporary profile in
> > > > > > > C:\Users\*.temp+lots of warnings and a note to log out
> > > > > > > immediately
> > > > > > > because your user profile dir has been "corrupted")
> > > > > > >
> > > > > > > Windows home dirs with NFSv4 only work so far with the
> > > > > > > Solaris&&Illumos NFS servers, and maybe the FreeBSD >= 14 NFS
> > > > > > > server
> > > > > > > (not tested yet).
> > > > > > I'll just note that the named attribute support (the windows
> > > > > > client
> > > > > > folk like the name)
> > > > > > along with Hidden and System are in 15 only.
> > > > > > And Archive is not supported because it is listed as "deprecated"
> > > > > > in the RFC.
> > > > > > (If this case really needs it, someone should try to get it
> > > > > > "undeprecated" on
> > > > > > nfsv4@ietf.org. I could add Archive easily. All of these are for
> > > > > > ZFS only.
> > > > > > ZFS also knows case insensitive, although I have not tried it.)
> > > > >
> > > > > Who (name!) had the idea to declare fattr4_archive as "deprecated"?
> > > > > It
> > > > > was explicitly added for Windows and DOS compatibility in NFSv4,
> > > > > and
> > > > > unlike Windows EAs (which are depreciated, and were superseded by
> > > > > "named streams") the "archive" attribute is still in use.
> > > > I have no idea who would have done this, but here is the snippet from
> > > > RFC5661 (which started being edited in 2005 and was published in
> > > > 2010,
> > > > so it has been like this for a long time). The same words are in
> > > > RFC8881
> > > > and currently in the RFC8881bis draft. Can this be changed?
> > > > I'd say yes, but it will take time and effort on someone's part.
> > > > Posting to nfsv4@ietf.org, noting that this attribute is needed
> > > > by the Windows client (and at least a suggestion that time_backup
> > > > is not a satisfactory replacement) would be a good start.
> > > >
> > > > 5.8.2.1.  Attribute 14: archive
> > > >
> > > >    TRUE, if this file has been archived since the time of last
> > > >    modification (deprecated in favor of time_backup).
> > > >
> > > > The problem has been a serious lack of Windows expertise in the NFSv4
> > > > working group. Long ago (20+ years) the Hummingbird developers were
> > > > actively involved (Hummingbird became Open Network Solutions, which
> > > > became a division of OpenText, if I recall it correctly).
> > > >
> > > > But there has been no one with Windows expertise involved more
> > > > recently.
> > > >
> > > > My suggestion (I'll repeat it) is to have someone participate in the
> > > > Bakeathon
> > > > testing events (the next one is in about one month and can be
> > > > attended
> > > > remotely using a tailscale VPN). When someone tests at the event and
> > > > finds an issue, the server developers are there and can discussion
> > > > what
> > > > it takes to fix it.
> > > >
> > > > Also, participation on the nfsv4@ietf.org mailing list (some working
> > > > group
> > > > members will not be reading this Linux list) and attendance at
> > > > working
> > > > group meetings would help. (The working group meetings can
> > > > also be attended remotely and there is an automatic fee waiver for
> > > > remote attendance if you, like me, are not funded to do the work.)
> > > >
> > > > With no involvement from people with Windows expertise, the testing
> > > > has become basically a bunch of servers being tested against by
> > > > various versions of the Linux client (with me being at outlier,
> > > > testing
> > > > the FreeBSD client).
> > >
> > > As stated in the line you quote, it is listed as being deprecated in
> > > favour of the backup time because the latter provides a superset of the
> > > same functionality: by comparing the value of the backup time to the
> > > value of the mtime, you can determine the value of the archive bit (it
> > > is set if the backup time is newer than the mtime).
> > >
> > > In addition, the backup time also tells you exactly when the file was
> > > last backed up.
> > >
> > > So no, this is not about people who don't understand Windows. It's
> > > about repackaging the same functionality in a way that is more useful
> > > to people who understand backups.
> >
> > fattr4_archive was added long ago by SUN and CITI for NFS4, for
> > feature parity with SMB, and to accurately map Windows and DOS
> > features (the "A" flag). It cannot be replaced by a timestamp, because
> > neither Windows nor DOS have a "backup timestamp", except in
> > specialised software.
> > It might have made sense from a Linux point of view, but that
> > literally disables the "archive" flag for Windows and DOS, with
> > chaotic consequences. An additional "backup timestamp" is nice, but in
> > this specific case it damages a platform.
>
> I hit <SEND> too early. The backup timestamp is fine, just declaring
> "fattr4_archive"

...as obsolete...

> is premature, unless Windows as a platform is
> considered no longer supported by IETF. But then NFS should be renamed
> to LFS (linux file system)

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

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Jeff Layton]

On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote:
> On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
> > > > Date:   Wed May 21 16:50:46 2008 +1000
> > > > 
> > > >     dcache: Add case-insensitive support d_ci_add() routine
> > > 
> > > My memory must be quite faulty then. I remember there being significant
> > > controversy at the Park City LSF around some patches adding support for
> > > case insensitivity. But so be it -- I must not have paid terribly close
> > > attention due to lack of oxygen.
> > 
> > Well, that is when the ext4 CI code landed, which added the unicode
> > normalization, and with that another whole bunch of issues.
> 
> Well, no one likes the Han unification, and the mess the Unicode
> consortium made from that,
> But the Chinese are working on a replacement standard for Unicode, so
> that will be a lot of FUN =:-)
> 
> > > > That being said no one ever intended any of these to be exported over
> > > > NFS, and I also question the sanity of anyone wanting to use case
> > > > insensitive file systems over NFS.
> > > 
> > > My sense is that case insensitivity for NFS exports is for Windows-based
> > > clients
> > 
> > I still question the sanity of anyone using a Windows NFS client in
> > general, but even more so on a case insensitive file system :)
> 
> Well, if you want one and the same homedir on both Linux and Windows,
> then you have the option between the SMB/CIFS and the Windows NFSv4.2
> driver (I'm not counting the Windows NFSv3 driver due lack of ACL
> support).
> Both, as of September 2025, work fine for us for production usage.
> 
> > > Does it, for example, make sense for NFSD to query the file system
> > > on its case sensitivity when it prepares an NFSv3 PATHCONF response?
> > > Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
> > > of internationalized file names?
> > 
> > Linus hates pathconf any anything like it with passion.  Altough we
> > basically got it now with statx by tacking it onto a fast path
> > interface instead, which he now obviously also hates.  But yes, nfsd
> > not beeing able to query lots of attributes, including actual important
> > ones is largely due to the lack of proper VFS interfaces.
> 
> What does Linus recommend as an alternative to pathconf()?
> 
> Also, AGAIN the question:
> Due lack of a VFS interface and the urgend use case of needing to
> export a case-insensitive filesystem via NFSv4.x, could we please get
> two /etc/exports options, one setting the case-insensitive boolean
> (true, false, get-default-from-fs) and one for case-preserving (true,
> false, get-default-from-fs)?
> 
> So far LInux nfsd does the WRONG thing here, and exports even
> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> server does it correctly.
> 
> Ced

I think you don't want an export option for this.

It sounds like what we really need is a mechanism to determine whether
the inode the client is doing a GETATTR against lies on a case-
insensitive mount.

Is there a way to detect that in the kernel?
-- 
Jeff Layton <jlayton@kernel.org>

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 9/10/25 7:10 AM, Jeff Layton wrote:
> On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote:
>> On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
>>>
>>> On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
>>>>> Date:   Wed May 21 16:50:46 2008 +1000
>>>>>
>>>>>     dcache: Add case-insensitive support d_ci_add() routine
>>>>
>>>> My memory must be quite faulty then. I remember there being significant
>>>> controversy at the Park City LSF around some patches adding support for
>>>> case insensitivity. But so be it -- I must not have paid terribly close
>>>> attention due to lack of oxygen.
>>>
>>> Well, that is when the ext4 CI code landed, which added the unicode
>>> normalization, and with that another whole bunch of issues.
>>
>> Well, no one likes the Han unification, and the mess the Unicode
>> consortium made from that,
>> But the Chinese are working on a replacement standard for Unicode, so
>> that will be a lot of FUN =:-)
>>
>>>>> That being said no one ever intended any of these to be exported over
>>>>> NFS, and I also question the sanity of anyone wanting to use case
>>>>> insensitive file systems over NFS.
>>>>
>>>> My sense is that case insensitivity for NFS exports is for Windows-based
>>>> clients
>>>
>>> I still question the sanity of anyone using a Windows NFS client in
>>> general, but even more so on a case insensitive file system :)
>>
>> Well, if you want one and the same homedir on both Linux and Windows,
>> then you have the option between the SMB/CIFS and the Windows NFSv4.2
>> driver (I'm not counting the Windows NFSv3 driver due lack of ACL
>> support).
>> Both, as of September 2025, work fine for us for production usage.
>>
>>>> Does it, for example, make sense for NFSD to query the file system
>>>> on its case sensitivity when it prepares an NFSv3 PATHCONF response?
>>>> Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
>>>> of internationalized file names?
>>>
>>> Linus hates pathconf any anything like it with passion.  Altough we
>>> basically got it now with statx by tacking it onto a fast path
>>> interface instead, which he now obviously also hates.  But yes, nfsd
>>> not beeing able to query lots of attributes, including actual important
>>> ones is largely due to the lack of proper VFS interfaces.
>>
>> What does Linus recommend as an alternative to pathconf()?
>>
>> Also, AGAIN the question:
>> Due lack of a VFS interface and the urgend use case of needing to
>> export a case-insensitive filesystem via NFSv4.x, could we please get
>> two /etc/exports options, one setting the case-insensitive boolean
>> (true, false, get-default-from-fs) and one for case-preserving (true,
>> false, get-default-from-fs)?
>>
>> So far LInux nfsd does the WRONG thing here, and exports even
>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
>> server does it correctly.
>>
>> Ced
> 
> I think you don't want an export option for this.
> 
> It sounds like what we really need is a mechanism to determine whether
> the inode the client is doing a GETATTR against lies on a case-
> insensitive mount.
> 
> Is there a way to detect that in the kernel?

Agreed, I would prefer something automatic rather than an explicit
export option. The best approach is to set this behavior on the
underlying file system via its mount options or on-disk settings.
That way, remote and local users see the exact same CS behavior.

An export option would enable NFSD to lie about case sensitivity.
Maybe that's what is needed? I don't really know. It seems like
a potential interoperability disaster.

Moreover, as we determined the last time this thread was active,
ext4 has a per-directory case insensitivity setting. The NFS
protocol's CS attribute is per file system. That's a giant mismatch
in semantics, and I don't know what to do about that. An export
option would basically override all of that -- as a hack -- but
would get us moving forward. Again, perhaps there are some
significant risks to this approach.


-- 
Chuck Lever

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Jeff Layton]

On Wed, 2025-09-10 at 10:14 -0400, Chuck Lever wrote:
> On 9/10/25 7:10 AM, Jeff Layton wrote:
> > On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote:
> > > On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
> > > > 
> > > > On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
> > > > > > Date:   Wed May 21 16:50:46 2008 +1000
> > > > > > 
> > > > > >     dcache: Add case-insensitive support d_ci_add() routine
> > > > > 
> > > > > My memory must be quite faulty then. I remember there being significant
> > > > > controversy at the Park City LSF around some patches adding support for
> > > > > case insensitivity. But so be it -- I must not have paid terribly close
> > > > > attention due to lack of oxygen.
> > > > 
> > > > Well, that is when the ext4 CI code landed, which added the unicode
> > > > normalization, and with that another whole bunch of issues.
> > > 
> > > Well, no one likes the Han unification, and the mess the Unicode
> > > consortium made from that,
> > > But the Chinese are working on a replacement standard for Unicode, so
> > > that will be a lot of FUN =:-)
> > > 
> > > > > > That being said no one ever intended any of these to be exported over
> > > > > > NFS, and I also question the sanity of anyone wanting to use case
> > > > > > insensitive file systems over NFS.
> > > > > 
> > > > > My sense is that case insensitivity for NFS exports is for Windows-based
> > > > > clients
> > > > 
> > > > I still question the sanity of anyone using a Windows NFS client in
> > > > general, but even more so on a case insensitive file system :)
> > > 
> > > Well, if you want one and the same homedir on both Linux and Windows,
> > > then you have the option between the SMB/CIFS and the Windows NFSv4.2
> > > driver (I'm not counting the Windows NFSv3 driver due lack of ACL
> > > support).
> > > Both, as of September 2025, work fine for us for production usage.
> > > 
> > > > > Does it, for example, make sense for NFSD to query the file system
> > > > > on its case sensitivity when it prepares an NFSv3 PATHCONF response?
> > > > > Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
> > > > > of internationalized file names?
> > > > 
> > > > Linus hates pathconf any anything like it with passion.  Altough we
> > > > basically got it now with statx by tacking it onto a fast path
> > > > interface instead, which he now obviously also hates.  But yes, nfsd
> > > > not beeing able to query lots of attributes, including actual important
> > > > ones is largely due to the lack of proper VFS interfaces.
> > > 
> > > What does Linus recommend as an alternative to pathconf()?
> > > 
> > > Also, AGAIN the question:
> > > Due lack of a VFS interface and the urgend use case of needing to
> > > export a case-insensitive filesystem via NFSv4.x, could we please get
> > > two /etc/exports options, one setting the case-insensitive boolean
> > > (true, false, get-default-from-fs) and one for case-preserving (true,
> > > false, get-default-from-fs)?
> > > 
> > > So far LInux nfsd does the WRONG thing here, and exports even
> > > case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> > > server does it correctly.
> > > 
> > > Ced
> > 
> > I think you don't want an export option for this.
> > 
> > It sounds like what we really need is a mechanism to determine whether
> > the inode the client is doing a GETATTR against lies on a case-
> > insensitive mount.
> > 
> > Is there a way to detect that in the kernel?
> 
> Agreed, I would prefer something automatic rather than an explicit
> export option. The best approach is to set this behavior on the
> underlying file system via its mount options or on-disk settings.
> That way, remote and local users see the exact same CS behavior.
> 
> An export option would enable NFSD to lie about case sensitivity.
> Maybe that's what is needed? I don't really know. It seems like
> a potential interoperability disaster.
> 

There is also the issue that exports can span filesystems. If you have
one fs that is case-sensitive mounted on another that is not, and then
you export the whole mess, the results sound sketchy.

> Moreover, as we determined the last time this thread was active,
> ext4 has a per-directory case insensitivity setting. The NFS
> protocol's CS attribute is per file system. That's a giant mismatch
> in semantics, and I don't know what to do about that. An export
> option would basically override all of that -- as a hack -- but
> would get us moving forward. Again, perhaps there are some
> significant risks to this approach.
> 

The spec is written such that case-sensitivity applies to the whole fs,
but in practical terms, would there be any harm in allowing this to be
set more granularly?

Existing servers would still work fine in that case, and I don't think
it would be an issue for the Linux client at least.
-- 
Jeff Layton <jlayton@kernel.org>

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Chuck Lever]

On 9/10/25 10:30 AM, Jeff Layton wrote:
> On Wed, 2025-09-10 at 10:14 -0400, Chuck Lever wrote:
>> On 9/10/25 7:10 AM, Jeff Layton wrote:
>>> On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote:
>>>> On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
>>>>>
>>>>> On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
>>>>>>> Date:   Wed May 21 16:50:46 2008 +1000
>>>>>>>
>>>>>>>     dcache: Add case-insensitive support d_ci_add() routine
>>>>>>
>>>>>> My memory must be quite faulty then. I remember there being significant
>>>>>> controversy at the Park City LSF around some patches adding support for
>>>>>> case insensitivity. But so be it -- I must not have paid terribly close
>>>>>> attention due to lack of oxygen.
>>>>>
>>>>> Well, that is when the ext4 CI code landed, which added the unicode
>>>>> normalization, and with that another whole bunch of issues.
>>>>
>>>> Well, no one likes the Han unification, and the mess the Unicode
>>>> consortium made from that,
>>>> But the Chinese are working on a replacement standard for Unicode, so
>>>> that will be a lot of FUN =:-)
>>>>
>>>>>>> That being said no one ever intended any of these to be exported over
>>>>>>> NFS, and I also question the sanity of anyone wanting to use case
>>>>>>> insensitive file systems over NFS.
>>>>>>
>>>>>> My sense is that case insensitivity for NFS exports is for Windows-based
>>>>>> clients
>>>>>
>>>>> I still question the sanity of anyone using a Windows NFS client in
>>>>> general, but even more so on a case insensitive file system :)
>>>>
>>>> Well, if you want one and the same homedir on both Linux and Windows,
>>>> then you have the option between the SMB/CIFS and the Windows NFSv4.2
>>>> driver (I'm not counting the Windows NFSv3 driver due lack of ACL
>>>> support).
>>>> Both, as of September 2025, work fine for us for production usage.
>>>>
>>>>>> Does it, for example, make sense for NFSD to query the file system
>>>>>> on its case sensitivity when it prepares an NFSv3 PATHCONF response?
>>>>>> Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
>>>>>> of internationalized file names?
>>>>>
>>>>> Linus hates pathconf any anything like it with passion.  Altough we
>>>>> basically got it now with statx by tacking it onto a fast path
>>>>> interface instead, which he now obviously also hates.  But yes, nfsd
>>>>> not beeing able to query lots of attributes, including actual important
>>>>> ones is largely due to the lack of proper VFS interfaces.
>>>>
>>>> What does Linus recommend as an alternative to pathconf()?
>>>>
>>>> Also, AGAIN the question:
>>>> Due lack of a VFS interface and the urgend use case of needing to
>>>> export a case-insensitive filesystem via NFSv4.x, could we please get
>>>> two /etc/exports options, one setting the case-insensitive boolean
>>>> (true, false, get-default-from-fs) and one for case-preserving (true,
>>>> false, get-default-from-fs)?
>>>>
>>>> So far LInux nfsd does the WRONG thing here, and exports even
>>>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
>>>> server does it correctly.
>>>>
>>>> Ced
>>>
>>> I think you don't want an export option for this.
>>>
>>> It sounds like what we really need is a mechanism to determine whether
>>> the inode the client is doing a GETATTR against lies on a case-
>>> insensitive mount.
>>>
>>> Is there a way to detect that in the kernel?
>>
>> Agreed, I would prefer something automatic rather than an explicit
>> export option. The best approach is to set this behavior on the
>> underlying file system via its mount options or on-disk settings.
>> That way, remote and local users see the exact same CS behavior.
>>
>> An export option would enable NFSD to lie about case sensitivity.
>> Maybe that's what is needed? I don't really know. It seems like
>> a potential interoperability disaster.
>>
> 
> There is also the issue that exports can span filesystems. If you have
> one fs that is case-sensitive mounted on another that is not, and then
> you export the whole mess, the results sound sketchy.
> 
>> Moreover, as we determined the last time this thread was active,
>> ext4 has a per-directory case insensitivity setting. The NFS
>> protocol's CS attribute is per file system. That's a giant mismatch
>> in semantics, and I don't know what to do about that. An export
>> option would basically override all of that -- as a hack -- but
>> would get us moving forward. Again, perhaps there are some
>> significant risks to this approach.
>>
> 
> The spec is written such that case-sensitivity applies to the whole fs,
> but in practical terms, would there be any harm in allowing this to be
> set more granularly?
> 
> Existing servers would still work fine in that case, and I don't think
> it would be an issue for the Linux client at least.

Yep, the issue is how existing NFS client implementations treat
fattr4_case_insensitive and fattr4_case_preserving. Research is
needed.


-- 
Chuck Lever

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Wed, 10 Sept 2025 at 16:35, Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On 9/10/25 10:30 AM, Jeff Layton wrote:
> > On Wed, 2025-09-10 at 10:14 -0400, Chuck Lever wrote:
> >> On 9/10/25 7:10 AM, Jeff Layton wrote:
> >>> On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote:
> >>>> On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
> >>>>>
> >>>>> On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
> >>>>>>> Date:   Wed May 21 16:50:46 2008 +1000
> >>>>>>>
> >>>>>>>     dcache: Add case-insensitive support d_ci_add() routine
> >>>>>>
> >>>>>> My memory must be quite faulty then. I remember there being significant
> >>>>>> controversy at the Park City LSF around some patches adding support for
> >>>>>> case insensitivity. But so be it -- I must not have paid terribly close
> >>>>>> attention due to lack of oxygen.
> >>>>>
> >>>>> Well, that is when the ext4 CI code landed, which added the unicode
> >>>>> normalization, and with that another whole bunch of issues.
> >>>>
> >>>> Well, no one likes the Han unification, and the mess the Unicode
> >>>> consortium made from that,
> >>>> But the Chinese are working on a replacement standard for Unicode, so
> >>>> that will be a lot of FUN =:-)
> >>>>
> >>>>>>> That being said no one ever intended any of these to be exported over
> >>>>>>> NFS, and I also question the sanity of anyone wanting to use case
> >>>>>>> insensitive file systems over NFS.
> >>>>>>
> >>>>>> My sense is that case insensitivity for NFS exports is for Windows-based
> >>>>>> clients
> >>>>>
> >>>>> I still question the sanity of anyone using a Windows NFS client in
> >>>>> general, but even more so on a case insensitive file system :)
> >>>>
> >>>> Well, if you want one and the same homedir on both Linux and Windows,
> >>>> then you have the option between the SMB/CIFS and the Windows NFSv4.2
> >>>> driver (I'm not counting the Windows NFSv3 driver due lack of ACL
> >>>> support).
> >>>> Both, as of September 2025, work fine for us for production usage.
> >>>>
> >>>>>> Does it, for example, make sense for NFSD to query the file system
> >>>>>> on its case sensitivity when it prepares an NFSv3 PATHCONF response?
> >>>>>> Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
> >>>>>> of internationalized file names?
> >>>>>
> >>>>> Linus hates pathconf any anything like it with passion.  Altough we
> >>>>> basically got it now with statx by tacking it onto a fast path
> >>>>> interface instead, which he now obviously also hates.  But yes, nfsd
> >>>>> not beeing able to query lots of attributes, including actual important
> >>>>> ones is largely due to the lack of proper VFS interfaces.
> >>>>
> >>>> What does Linus recommend as an alternative to pathconf()?
> >>>>
> >>>> Also, AGAIN the question:
> >>>> Due lack of a VFS interface and the urgend use case of needing to
> >>>> export a case-insensitive filesystem via NFSv4.x, could we please get
> >>>> two /etc/exports options, one setting the case-insensitive boolean
> >>>> (true, false, get-default-from-fs) and one for case-preserving (true,
> >>>> false, get-default-from-fs)?
> >>>>
> >>>> So far LInux nfsd does the WRONG thing here, and exports even
> >>>> case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> >>>> server does it correctly.
> >>>>
> >>>> Ced
> >>>
> >>> I think you don't want an export option for this.
> >>>
> >>> It sounds like what we really need is a mechanism to determine whether
> >>> the inode the client is doing a GETATTR against lies on a case-
> >>> insensitive mount.
> >>>
> >>> Is there a way to detect that in the kernel?
> >>
> >> Agreed, I would prefer something automatic rather than an explicit
> >> export option. The best approach is to set this behavior on the
> >> underlying file system via its mount options or on-disk settings.
> >> That way, remote and local users see the exact same CS behavior.
> >>
> >> An export option would enable NFSD to lie about case sensitivity.
> >> Maybe that's what is needed? I don't really know. It seems like
> >> a potential interoperability disaster.
> >>
> >
> > There is also the issue that exports can span filesystems. If you have
> > one fs that is case-sensitive mounted on another that is not, and then
> > you export the whole mess, the results sound sketchy.
> >
> >> Moreover, as we determined the last time this thread was active,
> >> ext4 has a per-directory case insensitivity setting. The NFS
> >> protocol's CS attribute is per file system. That's a giant mismatch
> >> in semantics, and I don't know what to do about that. An export
> >> option would basically override all of that -- as a hack -- but
> >> would get us moving forward. Again, perhaps there are some
> >> significant risks to this approach.
> >>
> >
> > The spec is written such that case-sensitivity applies to the whole fs,
> > but in practical terms, would there be any harm in allowing this to be
> > set more granularly?
> >
> > Existing servers would still work fine in that case, and I don't think
> > it would be an issue for the Linux client at least.
>
> Yep, the issue is how existing NFS client implementations treat
> fattr4_case_insensitive and fattr4_case_preserving. Research is
> needed.
>

It is per-filesystem.

Windows 10/11 NTFS has an optional per-directory, but that causes all
kinds of trouble, and per-directory case-insensitivity might be
depreciated soon again (ReFS chokes on it).

My recommendation is to stick with the per-filesystem setting.

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

Re: NFSv4.x export options to mark export as case-insensitive, case-preserving? Re: LInux NFSv4.1 client and server- case insensitive filesystems supported?

[Cedric Blancher]

On Wed, 10 Sept 2025 at 13:10, Jeff Layton <jlayton@kernel.org> wrote:
>
> On Tue, 2025-09-09 at 18:06 +0200, Cedric Blancher wrote:
> > On Tue, 10 Jun 2025 at 07:34, Christoph Hellwig <hch@infradead.org> wrote:
> > >
> > > On Mon, Jun 09, 2025 at 10:16:24AM -0400, Chuck Lever wrote:
> > > > > Date:   Wed May 21 16:50:46 2008 +1000
> > > > >
> > > > >     dcache: Add case-insensitive support d_ci_add() routine
> > > >
> > > > My memory must be quite faulty then. I remember there being significant
> > > > controversy at the Park City LSF around some patches adding support for
> > > > case insensitivity. But so be it -- I must not have paid terribly close
> > > > attention due to lack of oxygen.
> > >
> > > Well, that is when the ext4 CI code landed, which added the unicode
> > > normalization, and with that another whole bunch of issues.
> >
> > Well, no one likes the Han unification, and the mess the Unicode
> > consortium made from that,
> > But the Chinese are working on a replacement standard for Unicode, so
> > that will be a lot of FUN =:-)
> >
> > > > > That being said no one ever intended any of these to be exported over
> > > > > NFS, and I also question the sanity of anyone wanting to use case
> > > > > insensitive file systems over NFS.
> > > >
> > > > My sense is that case insensitivity for NFS exports is for Windows-based
> > > > clients
> > >
> > > I still question the sanity of anyone using a Windows NFS client in
> > > general, but even more so on a case insensitive file system :)
> >
> > Well, if you want one and the same homedir on both Linux and Windows,
> > then you have the option between the SMB/CIFS and the Windows NFSv4.2
> > driver (I'm not counting the Windows NFSv3 driver due lack of ACL
> > support).
> > Both, as of September 2025, work fine for us for production usage.
> >
> > > > Does it, for example, make sense for NFSD to query the file system
> > > > on its case sensitivity when it prepares an NFSv3 PATHCONF response?
> > > > Or perhaps only for NFSv4, since NFSv4 pretends to have some recognition
> > > > of internationalized file names?
> > >
> > > Linus hates pathconf any anything like it with passion.  Altough we
> > > basically got it now with statx by tacking it onto a fast path
> > > interface instead, which he now obviously also hates.  But yes, nfsd
> > > not beeing able to query lots of attributes, including actual important
> > > ones is largely due to the lack of proper VFS interfaces.
> >
> > What does Linus recommend as an alternative to pathconf()?
> >
> > Also, AGAIN the question:
> > Due lack of a VFS interface and the urgend use case of needing to
> > export a case-insensitive filesystem via NFSv4.x, could we please get
> > two /etc/exports options, one setting the case-insensitive boolean
> > (true, false, get-default-from-fs) and one for case-preserving (true,
> > false, get-default-from-fs)?
> >
> > So far LInux nfsd does the WRONG thing here, and exports even
> > case-insensitive filesystems as case-sensitive. The Windows NFSv4.1
> > server does it correctly.
> >
> > Ced
>
> I think you don't want an export option for this.
>
> It sounds like what we really need is a mechanism to determine whether
> the inode the client is doing a GETATTR against lies on a case-
> insensitive mount.

<rant>
It might sound rude, but after reading that I had to empty my bottle
of bromhydrate de scopolamine renaudin.
The topic of returning the correct booleans for fattr_case_insensitive
and fattr_case_preserving in Linux has been running in circles since
(at least) 2008, covering all kinds of bug reports (CITI, Suse, RH,
....) and mailing lists.
So far NOTHING ever happened, except "more research", "no time" and so
on, while other platforms like the Windows Server 2019 platform and
the Exceed/OpenText NFS4 server just did it correctly.
Exceed NFS client handles it correctly.
</rant>

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