On Wed, 26 Feb 2025 at 17:29, Corinna Vinschen via Cygwin <cygwin@cygwin.com> wrote: > > 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
This might not be trivial if we want to be generic and also include the OpenText folks. ms-nfs41-client and the Exceed/OpenText NFSv4 clients are completely different projects. But I just had a chat with Chuck Lever <chuck.le...@oracle.com>, maybe ORACLE can find someone in Microsoft to get new WNNC_NET_* values registered. I would prefer the official way, e.g. get new WNNC_NET_* values registered, instead of letting Cygwin suffer from more workarounds. Ced -- Cedric Blancher <cedric.blanc...@gmail.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
