X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org AF9A4385E012
Authentication-Results:	sourceware.org;
	dmarc=none (p=none dis=none) header.from=towo.net
Authentication-Results:	sourceware.org; spf=none smtp.mailfrom=towo AT towo DOT net
Subject:	Re: WSL symbolic links
To:	cygwin AT cygwin DOT com
References:	<294944bd-757e-4bb8-6bcc-ceb8d9190ef9 AT towo DOT net>
	<20200326110059 DOT GG3261 AT calimero DOT vinschen DOT de>
	<901e1c08-46cb-555b-c0d0-5bf9c726b3ca AT SystematicSw DOT ab DOT ca>
	<20200326195615 DOT GJ3261 AT calimero DOT vinschen DOT de>
	<8e330046-97bb-ba3e-15dc-25aedf915d90 AT towo DOT net>
	<20200327112115 DOT GL3261 AT calimero DOT vinschen DOT de>
From:	Thomas Wolff <towo AT towo DOT net>
X-Tagtoolbar-Keys:	D20200327132430741
Message-ID:	<ba4000a3-74d2-2a3c-f6ea-6bf4fa934b8b@towo.net>
Date:	Fri, 27 Mar 2020 13:24:30 +0100
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
	Thunderbird/68.6.0
MIME-Version:	1.0
In-Reply-To:	<20200327112115.GL3261@calimero.vinschen.de>
X-Provags-ID:	V03:K1:KXUXsbs6VWJ7z3WMNJB6YRlp1DOnD/UOCB5Hp3Lm5tIkgIc02zI
	Nlgc5L0NFG62nSaWnW1oMgJ1cmkwrkNhzkHCbaZLrbQWUX8gqt/ewnfOtRmS2/e71cJMqiL
	GUOx0E0Y07XHAYkSDAbQ8Z1fuiwda/dKQ7feXN90ou70YMBKwnKYBKQP0yXc/PhRO0G5KmI
	ZZoFCIlOwiTZBa0X3tFQA==
X-UI-Out-Filterresults:	notjunk:1;V03:K0:OaHWvSm2KjI=:QTXqTO70pNgUJy1s2FNyKL
	Be0Zf78e9Z71EHY/Nmq1ppBrz+DxXaLLujAtgA3rUxr5cfabWK8N8WlJPcqgU3wms1p0e1ZBS
	3Y8kFcPCbcrYirJncVpbVOvIAZXuBigJFvhQ2H76biHRp1wqN3rz4fIdsIb29AWidGxDZUUp2
	pC0aW+kYBEB8LeS9POFZcN9RbeoeKytQeXOfJdYcsyG2qC7IJNKlKKOZgLfYSGTVrnX56dnYD
	s0pb9n/zvFd5Bo8yEWP3xcD9EHVlhxBL+FVctlklJuURb0Q9uJ3eJhPaMX9We3tEYyCPohVAF
	Yjljq5gMr7iWtqVqCLgo17+ob3RbZzLqp+Bofl0eGJEaHoHJjYldYqveHiz9FmZN3ues8JbXR
	KcKi57wlygn3aNip5I8SrrPTRD18igwMxPQRyBnXpPRtKJzN0HPWeuLEoPw++tS4TBVSpZvP+
	BK8uooTmKyhWKP85zHhkEBO/yF/y0wMwUO61NZprNKh8/qMhhEsn8z1gznkThiTx8QY52C+3s
	lRqNR5FLNhsPlREouKc5Cuh9OT4DKYhAmk9Pk3toOcUOgQrZx6ox1WHUJbXZ6W2rBtdDadSsS
	PGv5jQduGHjdG+1+zz2sFvTl4uIuMwW3JHIo3I4gChO2jOVsX7ERAuZFYTmE+VhI9fQj4XJ4U
	jtqPfuzmTD2bb7kUU6nlsywUqe7JHdCGU88o24DPGGeU55RVWfkIUHV7HMjF+ipKyaysVle8M
	Fs9fvz2FZd1RlFnJmvt/BlfuOgPrktxNucqJz8tQZemdmUqatVqFziJnChlWRiCXQmxFGpK/E
	SF7yNTqsZw3DfhztUlfzGaMAlsVEDtbY/uDqI1CixyogsVv7g0=
X-Spam-Status:	No, score=4.2 required=5.0 tests=BAYES_00, BODY_8BITS,
	GARBLED_BODY, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY,
	RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,
	SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2
X-Spam-Level:	****
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<http://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<http://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:	<http://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 02RCPBoU029858

Am 27.03.2020 um 12:21 schrieb Corinna Vinschen:
> On Mar 27 00:52, Thomas Wolff wrote:
>> Am 26.03.2020 um 20:56 schrieb Corinna Vinschen:
>>> This is a reparse point tag different from the normal Windows symlink
>>> reparse point tag, 0xa000000c.  Searching for this value shows this
>>> is defined in ntifs.h as IO_REPARSE_TAG_LX_SYMLINK.
>>>
>>> Unfortunately I don't see a definition of the reparse point data for
>>> that reparse point type.
>>>
>>> In your examples the data part looks like a 4 byte int value, being 2 in
>>> both of your examples, maybe a file type, followed by the path in
>>> multibyte, no trailing \0.
>>>
>>> Unfortunately, in both cases the path is relative, just the file name it
>>> points to.  To get more information, could one of you two please create
>>> a few more symlinks?
>>>
>>> - A symlink pointing to a local path, given in absolute path syntax.
>>>     I assume the path will be in POSIX syntax, contain slashes, but it
>>>     would be helpful to see it.
>>>
>>> - A symlink with a target path pointing to a remote file (what syntax
>>>     does this use?)
>>>
>>> - Last but not least, could you please create a symlink pointing to a
>>>     target with a non-ASCII char, e. g., some german umlaut?
>> Not sure what kind of remote you'd like to see. I have a 'net use'
>> (cifs/smbfs) mounted drive but couldn't mount it in WSL. Otherwise:
>>
>>> wsl -d Ubuntu ls -l link*
>> lrwxrwxrwx 1 towo towo  4 Mar 27 00:31 link -> file
>> lrwxrwxrwx 1 towo towo 15 Mar 27 00:31 link-abs -> /mnt/c/tmp/file
>> lrwxrwxrwx 1 towo towo  5 Mar 27 00:39 link-foo -> föö
>> lrwxrwxrwx 1 towo towo 16 Mar 27 00:39 link-foo-abs -> /mnt/c/tmp/föö
>>> rd-reparse '\??\C:\tmp\link' ; echo
>> ReparseTag:           0xa000001d
>> ReparseDataLength:             8
>> Reserved:                      0
>> 02 00 00 00 66 69 6c 65
>>> rd-reparse '\??\C:\tmp\link-abs' ; echo
>> ReparseTag:           0xa000001d
>> ReparseDataLength:            19
>> Reserved:                      0
>> 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66
>> 69 6c 65
>>> rd-reparse '\??\C:\tmp\link-foo' ; echo
>> ReparseTag:           0xa000001d
>> ReparseDataLength:             9
>> Reserved:                      0
>> 02 00 00 00 66 c3 b6 c3 b6
>>> rd-reparse '\??\C:\tmp\link-foo-abs' ; echo
>> ReparseTag:           0xa000001d
>> ReparseDataLength:            20
>> Reserved:                      0
>> 02 00 00 00 2f 6d 6e 74 2f 63 2f 74 6d 70 2f 66
>> c3 b6 c3 b6
> Thanks!  In the meantime I could fix my problems with the Windows Store
> and was finally able to install WSL for further testing.  See below.
>
>> If the link name itself contains non-ASCII, rd-reparse fails with
>> NtOpenFile: C0000034
> Yeah, that's expected.  The test app only handles filename with ASCII
> chars.
>
>>> It's questionable if supporting this new symlink type makes sense, but
>>> taking a closer look doesn't hurt, I guess.
>> Well, at least they should be deletable, I think.
> I debugged this now and I found that practically all problems, including
> the inability to delete the symlink, are a result of not being able to
> open the reparse point correctly as reparse point within Cygwin.  So as
> not to destroy something important, Cygwin only opens reparse points as
> reparse points if it recognizes the reparse point type.
>
> Consequentially, all immediate problems go away, as soon as Cygwin
> recognizes and handles the symlink :)
>
> So I created a patch and pushed it.  The latest developer snapshot from
> https://cygwin.com/snapshots/ contains this patch.
Works, great, thank you!
> Funny sidenote: Assuming you create symlinks pointing to files with
> non-UTF-8 chars, e. g., umlauts in ISO-8859-1, then the symlink converts
> *all* these chars to the Unicode REPLACEMENT CHARACTER 0xfffd.  I assume
> this will also happen if you try to create the file with these chars in
> the first place, so it's not much of a problem.
As Windows filenames are character strings as opposed to Linux filenames 
which are byte strings, some strange behaviour is unavoidable. I see:
$ wsl ls -l link_LW
lrwxrwxrwx    1 towo     towo            19 Mar 27 12:11 link_LW -> 
file_L_
$ ls -l link_LW
lrwxrwxrwx 1 towo Kein 11 27. Mrz 13:11 link_LW -> file_L_����
which looks OK for me.
Thomas
--
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 -