On Thu, 11 Sept 2025 at 17:33, Cedric Blancher
<cedric.blancher@xxxxxxxxx> wrote:
>
> On Thu, 11 Sept 2025 at 17:26, Trond Myklebust <trondmy@xxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxx.
> > > >
> > > > On Wed, 10 Sept 2025 at 15:38, Rick Macklem
> > > > <rick.macklem@xxxxxxxxx> wrote:
> > > > >
> > > > > On Wed, Sep 10, 2025 at 3:47 AM Roland Mainz
> > > > > <roland.mainz@xxxxxxxxxxx> wrote:
> > > > > >
> > > > > > On Tue, Sep 9, 2025 at 9:32 PM Chuck Lever
> > > > > > <chuck.lever@xxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > On 9/9/25 12:33 PM, Cedric Blancher wrote:
> > > > > > > > On Tue, 9 Sept 2025 at 18:12, Chuck Lever
> > > > > > > > <chuck.lever@xxxxxxxxxx> 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@xxxxxxxx. 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@xxxxxxxx, 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@xxxxxxxx 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@xxxxxxxxx>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
