On Wed, Feb 26, 2025 at 2:36 PM Corinna Vinschen via Cygwin <[email protected]> wrote: > > On Feb 26 11:15, Roland Mainz via Cygwin wrote: > > On Wed, Feb 26, 2025 at 2:22 AM Jeremy Drake via Cygwin > > <[email protected]> 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". ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [email protected] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) -- 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
