DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 51QGlghU237426
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 51QGlghU237426
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=heoksgZd
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 9BB353858D28
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1740588461;
	bh=m/8pHaO0IY/DyUNwCSsvU8PANjhC53B8agAAlMfpyFc=;
	h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=heoksgZdT5tt6PItUhpUidWx+PKGIDNSj/CqLJQiLEiQBa54rhA3JegHeS6aq59PF
	oOKJ2hTqtFImWFP9Jea216lfw1Ws80sw5ZT3BoTWvcvdlbcDgCwr1dnfcuOeU/I0Gp
	Y+MCLeeFn5bC4Qum0rbiUm6Bb/8Gg2tXgGoGfLvg=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org B57433858D26
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org B57433858D26
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1740588434; cv=none;
	b=A0JCG2/NWK4A0rNNzJ3Ohq5pnOB6hpPdpZET9ksmiyVkB6GHh/+zL+DS0Q22cc4aLVEU0VstgeoNoz03mcdlY6Xuz2/PPZeJikrr9wSkdBEPnBKGitQ+t53kkKj0md+5tOBkBsPMd6vrZdqamLx9lWoBksIEb3rgB88JntiQISg=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1740588434; c=relaxed/simple;
	bh=iRKi5IeZfqszklriEQoakuA1mLF2flXPsxbX+sgMGtA=;
	h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
	b=hKccAwGMqTXiiFQDmTVF7D/y6jrEg0BolH1iLZLhaXGEVrvSLUphVSd+q6r44XSeHb5gztbfU02qwTYxdNNCfvQzytSvPJaZVFP7VQ5Wh5Ztb7BE8Vgm6FKm5USmCFEEeSO7SDnSEJ/H52GQFI4TSKuFKQ4VMVwqNUBuGR/YjQE=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org B57433858D26
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20230601; t=1740588432; x=1741193232;
	h=content-transfer-encoding:to:subject:message-id:date:from
	:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
	:subject:date:message-id:reply-to;
	bh=YJ8jtMXYWa/r/EO2PcwWOe2DoRHTyxA65q32TEJv8s8=;
	b=t0Bh+JoMMjHD6H1+GC29AssErpu1oigKD49qBKBIVXPo7V+VnrT8MpbUMN0eVKxtHW
	WMou/r52t3RjfZFIRiUr/7J3HzGObVTavFCRo8Nm8TsQC1eib512uM/PDUXOL0tqu1x2
	AcAAc1BBx640Twp3jrvp7Jw3lCiJTn2v3Ujr8ErUoXauZ03zVPNGfU9pamyBl3F9VGnr
	WRUPaQHpuuHbYdv6J3aKh1Zi3wZwrJr9M0yTbCRwNC0U5NMoCusSZ2a/fvLEDEfYyXUo
	t7+rLnPzsL0lB0bewKmEdfb4xEQXr5tidd2AmkFca01rI8XPOeSsuyupD9UzN4LBTL/0
	8UmA==
X-Gm-Message-State:	AOJu0YzcKnjmvp/8ObGEV/EW/6y0irVbnFDgni1ihrA86WDOWvwZvZJO
	emBUEcYo4uVx9GxHQPHY274fN/fMkf9uJXBFPmyTiUSZ3WyzjeYkz/Z2eVVEgRbLcsZ+DjTT+iG
	g8eOEZEKqzKdx7hOKz8zUDd+1n3Ole8Do
X-Gm-Gg:	ASbGnctk8qr6baLO/oD/HWtK9kLuGmVLBtWM1yQs6ATh7nR6vqBGr0Nh+fsP24TCrU7
	2DQKaCwi6RGte238YWP+KRBbd7VpJbC0vmWxrkLm+bJnI7IRqL2fA3KJbhkUkSbCa74/sxhv7TQ
	LcsCTEJ8g=
X-Google-Smtp-Source:	AGHT+IE13hY5xXDYxQrX0v13S49ZDGIZNE6TkvPxg+9C6goWXKmd0uSP7cBrdcXARDjrNxtpvMsHCcI4581XvMiCytI=
X-Received:	by 2002:a17:90b:4b0a:b0:2fa:1a8a:cff8 with SMTP id
	98e67ed59e1d1-2fe7e388617mr6435728a91.29.1740588432458; Wed, 26 Feb 2025
	08:47:12 -0800 (PST)
MIME-Version:	1.0
References:	<CALWcw=EqzTv-J5pm1DVT8Un+J2QWLtV70nF1nU9DO_P3Cg4OOg AT mail DOT gmail DOT com>
	<CALWcw=GDQ0kPGXBXMa3-9LdFX3fjsVdUK-VS1TpwdO_XtFvXMA AT mail DOT gmail DOT com>
	<Z73yniyu8UVlSafF AT calimero DOT vinschen DOT de>
	<CALWcw=HuN79qXaupYvXuFSWXNj0LmAxV4-EWsCgyYJ63xkVn1Q AT mail DOT gmail DOT com>
	<ba7af2e1-87e7-71fe-7a19-be5cd8587369 AT jdrake DOT com>
	<CAKAoaQnxk+OtYxHr_9g=0D6Pb9N1sDXjqNirt5LWze-apyybEw AT mail DOT gmail DOT com>
	<Z78Y5xXF_nIqsY9B AT calimero DOT vinschen DOT de>
	<CAKAoaQmkW-nE7q+uxRjjtd7-CGK_x38Eig29ys49ki2nOPJ5_w AT mail DOT gmail DOT com>
	<Z784PYxNn6DwIME0 AT calimero DOT vinschen DOT de>
	<CALXu0Uc4zCBZ=21gDWUVPomTxiUcvekctXwtB+mQNkbQ0C-oow AT mail DOT gmail DOT com>
	<Z79BLSfo1-EVqIqS AT calimero DOT vinschen DOT de>
In-Reply-To:	<Z79BLSfo1-EVqIqS@calimero.vinschen.de>
Date:	Wed, 26 Feb 2025 17:46:35 +0100
X-Gm-Features:	AWEUYZlgY94DfiK46JI0rtJsVPycmUq7J1Ev8cOYgoIeOVhSYQSkpjNtJBizgl8
Message-ID:	<CALXu0UcgAKLdreMmvcvMFtb0=OB-g7GqZJBjPjrEkn97eiiyag@mail.gmail.com>
Subject:	Re: Registering new |WNNC_NET_*| keys ? / Re: Document support for @
	character in UNC paths
To:	cygwin AT cygwin DOT com
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Cedric Blancher via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Cedric Blancher <cedric DOT blancher AT gmail DOT com>
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 51QGlghU237426

On Wed, 26 Feb 2025 at 17:29, Corinna Vinschen via Cygwin
<cygwin AT cygwin DOT 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 AT cygwin DOT 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 AT cygwin DOT 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 AT cygwin DOT 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 DOT lever AT oracle DOT 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 DOT blancher AT gmail DOT 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

- Raw text -