DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 56T70Die577487
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E07B3858C55
MIME-Version: 1.0
References: <CALXu0UfWK6MMe9CFBD547YYyqke=fNKoK3-TvGeJmaVo=HqiwA AT mail DOT gmail DOT com>
 <58d781a4-922f-d795-2396-688c2ac0e6d9 AT jdrake DOT com>
 <Z_T-y9OiJpkw7jdg AT calimero DOT vinschen DOT de>
In-Reply-To: <Z_T-y9OiJpkw7jdg@calimero.vinschen.de>
Date: Tue, 29 Jul 2025 08:54:24 +0200
Message-ID: <CALXu0Ucp5aJ=sUiQr4NPRYsVvGFXVeq0LBGYtCjydZkJc4AQ+w@mail.gmail.com>
Subject: Re: Windows Remote Driver Identification Re: Cygwin wishlist for
 NFSv4.2 driver?
To: cygwin AT cygwin DOT com
From: Cedric Blancher via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Cedric Blancher <cedric DOT blancher AT gmail DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On Tue, 8 Apr 2025 at 12:48, Corinna Vinschen via Cygwin
<cygwin AT cygwin DOT com> wrote:
>
> On Apr  3 14:28, Jeremy Drake via Cygwin wrote:
> > On Wed, 2 Apr 2025, Cedric Blancher via Cygwin wrote:
> >
> > > On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin
> > > <cygwin AT cygwin DOT com> wrote:
> > > > No, but if we want to *better* support this driver, we need either a
> > > > patch (preferred) or at least info how to distinguish in
> > > > fs_info::update(*) between the MSFT driver and the NFSv4.2 driver.
> > >
> > > That is actually easy: Roland implemented support for
> > > FileRemoteProtocolInformation in
> > > https://github.com/kofemann/ms-nfs41-client/commit/e9f72b61494bebd9e26fefec2659a4511a05b0fd
> > >  , and the FILE_REMOTE_PROTOCOL_INFORMATION->Protocol field can be
> > > used to identify the type of driver.
> > >
> > > Examples:
> > > Windows NFSv3 driver uses WNNC_NET_MS_NFS,
> > > OpenAFS uses WNNC_NET_OPENAFS, ms-nfs41-client uses
> > > WNNC_NET_RDR2SAMPLE, and OpenText NFS also uses WNNC_NET_RDR2SAMPLE.
> > >
> > > Plan for ms-nfs42-client is to obtain an own WNNC_NET_MSNFS42CLIENT
> > > tag, and also tags for DOKANY.
> >
> > I thought using WNNC to identify was brought up before and rejected.  At
> > this point, it's querying *volume* information, and has a volume handle.
> > It looks like you get FileRemoteProtocolInformation by querying a *file*
> > handle.  I could be wrong, and maybe that handle can be queried for
> > FileRemoteProtocolInformation, but it's not like that returns a unique
> > identifier either.
>
> Actually, while the Win32 API requires a volume handle, the underlying
> ntdll functions do not.  They only require a handle to a file or directory
> opened on the volume which is requested for volume information.
>
> Therefore, if possible, fs_info::update() just reuses the file handle
> from the current path_conv check in progress.
>
> Either way, WNNC is not what we're looking for, Jeremy is entirely
> on the right path here:
>
> > What I'm seeing of the things that come through volume information:
> > FileSystemName is either NFS or DEBUG-NFS41 (the latter at least looks
> > unique, if not intended for public consumption).
>
> fsname NFS isn't sufficient obviously.
>
> > The VolumeLabel is
> > PnfsVolume, the VolumeSerialNumber is always 0xBABAFACE (that's got to
> > suck for the "unique per-drive/share hash" mentioned in mount.cc), the
> > flags are set in
> > https://github.com/kofemann/ms-nfs41-client/blob/bf8d343ba2465926f3bfafa8407a69e79649cf46/daemon/nfs41_superblock.c#L173
>
> This is a bug in the nfs41 driver.  It should make an effort to generate
> a unique serial number and/or a unique volume label.  Why not generate a
> hash value from the remote path?  If it can't create a unique VSN, the
> VSN should be set to 0.  Otherwise, having the same non-0 VSN for all
> mounted NFS shares will lead to confusion.

I think Tigran and Roland fixed that.

>
> > What stands out to me in the flags is that they include
> > FILE_SUPPORTS_REMOTE_STORAGE.  I'm not sure what that's supposed to
> > mean, above and beyond FILE_REMOTE_DEVICE.
>
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/d4bc551b-7aaf-4b4f-ba0e-3a75e7c528f0#Appendix_A_167

Also fixed by Tigran and Roland.

>
> Setting this flag is wrong afaics.
>
> Can somebody with nfs41 installed just run
>
>
>   $ /usr/lib/csih/getVolInfo <path-to-nfs-share>
>
> and paste the output here?

As of last week's ms-nfs41-client HEAD I get this, but I added
comments in <...>:

/usr/lib/csih/getVolInfo.exe .
Device Type        : 0x07
Characteristics    : 0x00000030
  FILE_REMOVABLE_MEDIA              : FALSE
  FILE_REMOTE_DEVICE                : TRUE
Volume Name        : <nfs://derfwnb4966_ipv4:2049/>
Serial Number      : 2162811071
Max Filenamelength : 255
Filesystemname     : <NFS>
Flags              : 0x084000cf
  FILE_CASE_SENSITIVE_SEARCH        :
<negotiated-with-NFSv4-server,TRUE-for-btrfs/ext4fs/xfs>
  FILE_CASE_PRESERVED_NAMES         :
<negotiated-with-NFSv4-server,TRUE-for-btrfs/ext4f/xfss>
  FILE_UNICODE_ON_DISK              : TRUE
  FILE_PERSISTENT_ACLS              :
<negotiated-with-NFSv4-server,TRUE-for-Linux-btrfs/ext4fs+Solaris-nfsd+zfs>
  FILE_FILE_COMPRESSION             : FALSE
  FILE_VOLUME_QUOTAS                : FALSE
  FILE_SUPPORTS_SPARSE_FILES        :
<negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs/ext4fs/xfs>
  FILE_SUPPORTS_REPARSE_POINTS      :
<negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs/ext4fs/xfs>
  FILE_SUPPORTS_REMOTE_STORAGE      : FALSE
  FILE_RETURNS_CLEANUP_RESULT_INFO  : FALSE
  FILE_SUPPORTS_POSIX_UNLINK_RENAME : FALSE
  FILE_VOLUME_IS_COMPRESSED         : FALSE
  FILE_SUPPORTS_OBJECT_IDS          : FALSE
  FILE_SUPPORTS_ENCRYPTION          : FALSE
  FILE_NAMED_STREAMS                : FALSE
  FILE_READ_ONLY_VOLUME             : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE        : FALSE
  FILE_SUPPORTS_TRANSACTIONS        : FALSE
  FILE_SUPPORTS_HARD_LINKS          :
<negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs/ext4fs/xfs>
  FILE_SUPPORTS_EXTENDED_ATTRIBUTES :
<negotiated-with-NFSv4-server,TRUE-for-Solaris+Illumos-NFSv4.1-server+nfs4j-server,FALSE-for-Linux-nfsd>
  FILE_SUPPORTS_OPEN_BY_FILE_ID     : FALSE
  FILE_SUPPORTS_USN_JOURNAL         : FALSE
  FILE_SUPPORTS_INTEGRITY_STREAMS   : FALSE
  FILE_SUPPORTS_BLOCK_REFCOUNTING   :
<negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs//xfs,FALSE-for-ext4fs>
  FILE_SUPPORTS_SPARSE_VDL          : FALSE
  FILE_DAX_VOLUME                   : FALSE
  FILE_SUPPORTS_GHOSTING            : FALSE
SectorInfoFlags    : 0x07
  SSINFO_FLAGS_NO_SEEK_PENALTY      : TRUE
  SSINFO_FLAGS_TRIM_ENABLED         :
<negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs/ext4fs/xfs>

As you can see with NFSv4.1/NFSv4.2 the features set returned by
GetVolumeInformationByHandleW() is very flexible and depends on the
capabilities of the filesystem exported by nfsd.
For example FILE_CASE_SENSITIVE_SEARCH+FILE_CASE_PRESERVED_NAMES are
both TRUE for normal Linux+Solaris filesystems, but FALSE if FAT32 is
exported by the NFS server.
Same for FILE_SUPPORTS_BLOCK_REFCOUNTING, it depends on NFSv4.2
protocol support in the server, and whether the exported filesystem
supported file/block cloning - btrfs, bcachefs, xfs, zfs support this,
ext4 and fat32 do not. Hardlinks are not supported by FAT32, so the
NFSv4.2 client will not return TRUE in that case.
And that all applies to FILE_SUPPORTS_EXTENDED_ATTRIBUTES,
FILE_SUPPORTS_SPARSE_FILES and so on, too.

But you also get this kind of flexibility with SMB3.2, but much worse:
Server sets the defaults, and the admin on the client can override
this.

>
> > MS NFS only seems to set
> > FILE_CASE_PRESERVED_NAMES (2), so the existing flag song-and-dance could
> > probably be extended to tell the difference here.
> >
> > They're also always setting
> > SSINFO_FLAGS_ALIGNED_DEVICE|SSINFO_FLAGS_PARTITION_ALIGNED_ON_DEVIVE|
> > SSINFO_FLAGS_NO_SEEK_PENALTY.
>
> Could be helpful to distinguish between both NFS versions, but I don't
> trust Windows to set the flags if the server is a Windows machine.
> Or something.

SSINFO_FLAGS_NO_SEEK_PENALTY is tied to FILE_SUPPORTS_SPARSE_FILES for
ms-nfs41-client

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

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple