From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by sourceware.org (Postfix) with ESMTPS id AF9A4385E012 for ; Fri, 27 Mar 2020 12:24:31 +0000 (GMT) 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@towo.net Received: from [192.168.178.45] ([95.90.246.248]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MDgxt-1j89eL1r9j-00Ap0b for ; Fri, 27 Mar 2020 13:24:30 +0100 Subject: Re: WSL symbolic links To: cygwin@cygwin.com References: <294944bd-757e-4bb8-6bcc-ceb8d9190ef9@towo.net> <20200326110059.GG3261@calimero.vinschen.de> <901e1c08-46cb-555b-c0d0-5bf9c726b3ca@SystematicSw.ab.ca> <20200326195615.GJ3261@calimero.vinschen.de> <8e330046-97bb-ba3e-15dc-25aedf915d90@towo.net> <20200327112115.GL3261@calimero.vinschen.de> From: Thomas Wolff X-Tagtoolbar-Keys: D20200327132430741 Message-ID: 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> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 12:24:41 -0000 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