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.
Ced
--
Cedric Blancher <cedric.blancher@xxxxxxxxx>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
