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. 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). 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 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. 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. -- 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
