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@cygwin.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. > 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 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? > 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. Corinna -- 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
