DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 51Q1125Q4058094
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C6143858D26
Date: Tue, 25 Feb 2025 16:59:53 -0800 (PST)
To: Cedric Blancher <cedric.blancher@gmail.com>
cc: cygwin@cygwin.com
Subject: Re: Document support for @ character in UNC paths
In-Reply-To: <CALXu0UcjiJt4=MnuCWb_97FY9NVMM6Ak-5a87H2uR7qO+50Gzg@mail.gmail.com>
Message-ID: <d3cc4542-4664-a756-ccd3-f05515cc1d7b@jdrake.com>
References: <CALXu0UdHbasuyBiVZveyvJ1+K168QKBu0wn_cEVG8z+zfqQQeg@mail.gmail.com>
 <CAPJSo4XR+vG=RLrOwdo=TsVhLj+qRhDdu0CFrnDZn4Z0oSoqhQ@mail.gmail.com>
 <Z7dgP35hc_jd_dK7@calimero.vinschen.de>
 <CAPJSo4WrUzuGyTzz=Pp8oPnnbcawLNGZBb5dCE67AazVh8B2bA@mail.gmail.com>
 <Z7eSVamMjrs5XsBm@calimero.vinschen.de>
 <CANH4o6NW7NnygLoRgWmMMV7qY4UwK6vKnVKCRX2u=9MCWhdMdg@mail.gmail.com>
 <Z7hVWK1_pzYrIzBG@calimero.vinschen.de>
 <CALWcw=E4kcJ+UbsRkqkFpgRx734H33NhJhspuVH2KgDzV4jL3g@mail.gmail.com>
 <Z7my7gejHoLjf2F1@calimero.vinschen.de>
 <CALWcw=EqzTv-J5pm1DVT8Un+J2QWLtV70nF1nU9DO_P3Cg4OOg@mail.gmail.com>
 <CALWcw=GDQ0kPGXBXMa3-9LdFX3fjsVdUK-VS1TpwdO_XtFvXMA@mail.gmail.com>
 <CALXu0UcjiJt4=MnuCWb_97FY9NVMM6Ak-5a87H2uR7qO+50Gzg@mail.gmail.com>
MIME-Version: 1.0
Precedence: list
From: Jeremy Drake via Cygwin <cygwin@cygwin.com>
Reply-To: Jeremy Drake <cygwin@jdrake.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

On Tue, 25 Feb 2025, Cedric Blancher via Cygwin wrote:

> WebDAV and BeeGFS are not alone, the Windows ms-nfs41-client and
> ms-nfs42-client ALWAYS (even with default NFSv4.1 port TCP/2049) use
> UNC paths with "@" character, like
> \\stripe02.zebracluster.intra.pasteur.fr@2049\nfs4\disk02\
> OpenText NFSv4.0 client also supports that, but only if you not use
> the default NFSv4.0 TCP port.

Hmm, that's interesting (in a breaks-things kind of way).  Current code
assumes that server name containing "@" is webdav, and skips trying to
enumerate shares because that wasn't working for webdav.  Also, current
code does not try to enumerate nfs shares unless it can connect to server
on tcp port 2049.  It seems neither of these assumptions hold, and in fact
you cannot tell by name if
"\\stripe02.zebracluster.intra.pasteur.fr@2049\nfs4\disk02\" is a webdav
server on port 2049 or an nfs server on port 2049 (or potentially some
other kind of server).

BTW, this was not in an email so I don't have a message to reply to, but
in reply to 01bcd7d
> So far there's no known way to enumerate connected WebDAV resources.
> WNetGetResourceInformationW/WNetOpenEnumW both return ERROR_BAD_NET_NAME.
>
> However, `net use' enumerates the connected cloud shares, so
> there must be a way to do this.

Have you tried WNetOpenEnumW with RESOURCE_CONNECTED and/or
RESOURCE_REMEMBERED scopes?  Unfortunately, it looks like lpNetResource
must be NULL if the scope is not RESOURCE_GLOBALNET, so you just get a
list of all connected or remembered resources respectively, not only the
ones for a given server name and provider.  I guess you are expected to
filter them yourself.

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