From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58438 invoked by alias); 13 Feb 2017 19:34:31 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 58425 invoked by uid 89); 13 Feb 2017 19:34:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.3 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=pathcc, path.cc, UD:path.cc, 13022017 X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (212.227.126.135) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Feb 2017 19:34:20 +0000 Received: from [192.168.178.45] ([95.91.244.74]) by mrelayeu.kundenserver.de (mreue001 [212.227.15.167]) with ESMTPSA (Nemesis) id 0MG2eU-1cZZ1Q0Uqc-00EwM9 for ; Mon, 13 Feb 2017 20:34:18 +0100 Subject: Re: cygpath -w converts relative paths to absolute windows paths To: cygwin@cygwin.com References: <10eb657d-a00b-1609-a9b9-6373092c1ac1@polyhack.io> <20170212112314.GE11666@calimero.vinschen.de> <6055a8e1-bfd7-16c7-f25a-e02523863fdd@towo.net> <20170213151614.GA25846@calimero.vinschen.de> From: Thomas Wolff Message-ID: <797cd711-05a0-19f7-41b7-43321571da8c@towo.net> Date: Mon, 13 Feb 2017 19:34:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170213151614.GA25846@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:0nWY1+RTQrs=:VzHzVKkjQO7JsSBQxuTW7q ZjKYSVF6hGJxTLxTbtWWZaAJ49ikkweXq/hW+vemRDoGshuHJfSOmIAjvztL8lVDUReOg6SDn CnzxBcaxlBZg90Y/Lal6k4ICU26FMwJIrDXvD2WinZze53OyRvJfkScgqoXVivd+0iJ6wlF66 Uj8/FasNdGlP4uD6UfUKd6tnQ6u084YVf/6KlJpgXq8JWG8rxoIOq7Oopk81FHFolStZZbCCa R9FbxB6szmwKtm1nPSCpa1TakY5FWzqICraXfGGKOanLQmrxJTK0CGbE2iGYWECxv5YPeTcAb NQvNR7GXdSPkbCfgQtqe8Ui+nmhRCNMKEbXuKq5t0GoePe8dqFfP6w+IPI2zjGkcpFGgTj7YW E0UDWiVPKiYZI+k6K/b8FWamXNjC3nXk3wjZPUrng+/vcTHarDwyXH9XWwVk/+G7b3GQu/MOu Tign0xoArOK1AWLMLyAnQH/IhiN+GUZzIqMgRm2Kuz+tstCzDPEoXivYn132XhPmDN5gpyvcq ZPdDyIx6B4mjMNYKpr73J2gd6SsTQm7JlGC0oWfRPa9I6nJnYPvZG5shTuFEnzAL2SlgTWWdJ mRS+pF1fC3r1kwOzAjncBDtxsylCxHlvFRX0z37b2N22nS5KSUjaGeeY5HDCZHmq5OPWmD6uI LdOyazsFRNJwhwPBzHgVmxm6+w2cpvpIxqvDWG+3mEST1rgFLcMcX5lmyRV4H28dJtDmvs/F+ AoCQaJCHpjJUh6Q6 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00176.txt.bz2 Am 13.02.2017 um 16:16 schrieb Corinna Vinschen: > On Feb 12 18:38, Thomas Wolff wrote: >> Am 12.02.2017 um 12:23 schrieb Corinna Vinschen: >>> On Feb 7 14:35, Roger Qiu wrote: >>>> Hi, >>>> >>>> I've found that `cygpath --windows '../` will give back an absolute windows >>>> path. >>>> >>>> I thought this would only happen if you provide the `--absolute` flag, or >>>> when the path is a special cygwin path. >>>> >>>> But this occurs just for normal directories. >>>> >>>> I have come across a situation where I need to convert ntfs symlinks to unix >>>> symlinks and back. Sometimes these symlinks have relative paths them. Now by >>>> using cygpath --windows, I get back absolute paths, which means the >>>> integrity of the symlink isn't preserved. >>>> >>>> Can `cygpath --windows '../directory'` give back `..\directory` for paths >>>> aren't special cygwin paths? These relative backslashes are supported in >>>> Windows right now. >>> Not easily. All paths are evaluated as absolute paths inside Cygwin. >>> The result of the path conversion is always an absolute path. A relative >>> path is generated from there by checking if the path prefix in POSIX >>> notation is identical to the current working directory. If not, the >>> path stays absolute. Naturally, if you use a "..", the resulting path >>> does not match the CWD anymore, so you're out. >> How about converting getcwd(), too, and comparing that? > Converting to what? And how's that different from what I describe above? I was looking at path.cc, function mkrelpath, and (without tracing anything) assumed this would be the relevant function and had the impression that, when comparing path_prefix_p (cwd_win32, path, ...), path might be "normalized" (resolving links and folding ".." components) while cwd_win32 might not. If that's the case, it might be sufficient to "normalize" cwd_win32 as well. > Btw., did you see https://cygwin.com/ml/cygwin/2017-01/msg00404.html? No, I hadn't, sorry. Will respond there. ------ Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple