On Feb 26 17:13, Cedric Blancher via Cygwin wrote: > On Wed, 26 Feb 2025 at 16:50, Corinna Vinschen via Cygwin > <cygwin@cygwin.com> wrote: > > > > On Feb 26 16:23, Roland Mainz via Cygwin wrote: > > > On Wed, Feb 26, 2025 at 2:36 PM Corinna Vinschen via Cygwin > > > <cygwin@cygwin.com> wrote: > > > > > > > > On Feb 26 11:15, Roland Mainz via Cygwin wrote: > > > > > On Wed, Feb 26, 2025 at 2:22 AM Jeremy Drake via Cygwin > > > > > <cygwin@cygwin.com> wrote: > > > > > > On Tue, 25 Feb 2025, Takeshi Nishimura via Cygwin wrote: > > > > > > > No, it's beegfs.sys you install. > > > > > > > SMB is not used, it uses its own protocol. If you do a > > > > > > > FileRemoteProtocolInfo query the protocol field says it's a > > > > > > > WNNC_NET_RDR2SAMPLE. > > > > > > > > > > > > Always nice when a driver doesn't change "sample" idenfiers. It > > > > > > seems > > > > > > Virtualbox shared folders also squats on this identifier. I imagine > > > > > > things don't go well if one attempts to install beegfs.sys on a > > > > > > virtualbox > > > > > > virtual machine with their guest drivers installed... > > > > > > > > > > I think the problem is that no one in the OpenSource world really > > > > > knows how to register new |WNNC_NET_*| keys. QEmu shared folders, > > > > > DOKANY, ms-nfs41-client, etc. all use |WNNC_NET_RDR2SAMPLE| because > > > > > the sample filesystem code uses that. > > > > > > > > So if ms-nfs41-client uses WNNC_NET_RDR2SAMPLE, we don't have to handle > > > > these shares when checking the WNNC_NET_MS_NFS provider. While it would > > > > be nice if the nfs v4 driver would use some other WNNC type, > > > > > > Our plan is to get our own |WNNC_NET_*| key value if we can find the > > > person at Microsoft which is maintaining that list (preferred key > > > names would be |WNNC_NET_MSNFS41CLIENT| (for CITI's ms-nfs41-client) > > > and |WNNC_NET_MSNFS42CLIENT| for our version. > > > > > > And at the same time maybe help DOKANY&co to get their own > > > |WNNC_NET_*| key, too. > > > > > > > this is > > > > at least helpful for handling WNNC_NET_MS_NFS shares, because they > > > > have more than one quirk... > > > > > > I know... that's one reason we started working on the ms-nfs41-client > > > project, and at the same time it's API being compatible with the > > > MS-NFSv3 and the Exceed/OpenText-NFS drivers (that's why we support > > > the "NfsV3Attributes" (incl. uid/gid), "NfsSymlinkTargetName", > > > "NfsActOnLink" etc. Win32 extended attributes; > > > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/ff4df658-7f27-476a-8025-4074c0121eec > > > is still on the ToDo list) - but also extend the functionality, e.g. > > > support NFSv4.1 ACLs (mapped to Win32 ACLs via a script-driven > > > idmapper), sparse file support (for HPC environments), and > > > ms-nfs42-client will add AlternateDataStream support if the NFSv4.1 > > > server supports NFS "named attributes". > > > > I mentioned it months ago, and I mention it again: > > > > It would be really great if the filesystem name returned by > > NtQueryVolumeInformationFile(FileFsAttributeInformation) would not be > > "NFS", like the MS NFS, but something like "NFS4" or "NFSv4". This > > would allow Cygwin's fs_info::update() in mount.cc to recognize the > > filesystem as something special, and the code could call either the > > special NFS functions, or the Windows functions, or extra functions just > > for NFSv4 as time goes by. > > Well, that backfires because the same applications which want > NfsV3Attributes also look at FILE_FS_ATTRIBUTE_INFORMATION > FileSystemName, and STOP WORKING using NfsV3Attributes if it's not > "NFS". > From a driver's vendor position Exceed had that problem, OpenText > inherited that problem, CITI had to do it on Microsoft's instructions > (the CITI driver was a joint venture of SUN and Microsoft), and now > Roland&Tigran&CERN&DESY have to do it too.
I wasn't aware there are other projects using the undocumented NFS interfaces. As far as Cygwin is concerned, it would be the simplest thing to add a check for the "NFSv4" FS name and handle it accordingly. OTOH, there are other ways to differ between MS NFS and NFSv4 in fs_info::update(), for instance by checking the filesystem flags. MS NFS only sets FILE_CASE_PRESERVED_NAMES to TRUE, but no other flag. Therefore, if we know the flags, or a minimal set of flags NFSv4 sets, we can distinguish both NFS versions and ultimately add code handling NFSv4 different from MS NFS where necessary or prudent in the future. For an example of handling filesystems using the same FS name differently, see for instance the MINIMAL_WIN_NTFS_FLAGS in mount.cc: https://sourceware.org/cgit/newlib-cygwin/tree/winsup/cygwin/mount.cc#n391 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
