From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99649 invoked by alias); 13 Jun 2018 08:49:29 -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 92276 invoked by uid 89); 13 Jun 2018 08:48:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=much!, much, Hey X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Jun 2018 08:48:22 +0000 Received: from [62.225.77.164] ([62.225.77.164]) by 3c-app-gmx-bs06.server.lan (via HTTP); Wed, 13 Jun 2018 10:48:19 +0200 MIME-Version: 1.0 Message-ID: From: "Sven Eden" To: cygwin@cygwin.com Subject: Re: Problematic interpretion of paths starting with double slashes Content-Type: text/plain; charset=UTF-8 Date: Wed, 13 Jun 2018 13:05:00 -0000 Sensitivity: Normal In-Reply-To: <7a4567bc-3312-2da5-9e74-46afafa09fc1@redhat.com> References: <7a4567bc-3312-2da5-9e74-46afafa09fc1@redhat.com> X-UI-Message-Type: mail X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00140.txt.bz2 > Gesendet: Dienstag, 12. Juni 2018 um 19:56 Uhr > Von: "Eric Blake" > On 06/12/2018 08:14 AM, Sven Eden wrote: > > Good style is nice, but in my book, it is trumped by correct code. Yeah. Point taken. :-D > Hey, let's all assume good intent here. I did not mean what I wrote as > an attack against you, nor am I accusing you of writing the said code, > only that the code you are trying to use (shorthand "your code") is > relying on something non-portable, and is therefore worth improving, > regardless of whether Cygwin also makes a change. I apologize if my > words have come across in a different tone than intended (email tends to > be a lousy medium in that regards). And likewise, I'm not upset at your > reaction to my words. *sigh* ... you are absolutely correct of course. In hindsight, I interpreted more into written words than was available. I am sorry and apologize for being so "touchy". > >>> My question therefore is, whether the behavior can be gotten > >>> nearer what every other GNU/Linux system does. > >>> Maybe, if said first component can not be resolved as an smb > >>> host, try an absolute path instead? > >> > >> That won't work as nicely as you want, because you will introduce long > >> timeouts for every time that Cygwin first has to ascertain that '//tmp' > >> does not exist as a remote host. Maybe we could indeed make '//tmp' > >> resolve to '/tmp' if there is no remote '//tmp' available, but the speed > >> penalties in doing so will not make it pleasant. > > > > The speed penalties would only apply if > > a) "Something" looks up //foo/bar > > b) "Something" made a mistake and actually wanted > > /foo/bar > > > > So apart from the speed penalty that "Something" has to > > suffer, and its their own damn fault, the only real > > consequence would be that "Something" does not die from > > ENOENT any more. > > Indeed, and you may have a valid argument for making that change in > Cygwin; patches are certainly welcome (that is, since //tmp is already > implementation-defined behavior, we can define it to attempt to resolve > to the remove host first, and on ENOENT then attempt to resolve it > locally). It does have one potential minor drawback: right now, at > least bash hard-codes the assumption that on Cygwin, //foo and //foo/ > resolve identically (that is, IF //foo exists, it necessarily behaves as > a directory), using that assumption to reduce the need for network > queries during certain forms of tab completion. If we add the fallback > to trying /foo, that assumption is no longer always the case (it could > be a regular file, symlink, socket, ...). Hmm... that's a good point. So implemeting such a fallback can only be done for anything that is at least "//foo/". > > Am I right that the relevant stuff can be found in > > winsup/cygwin? > > Yes. Then I'll add experimenting with that idea on my TODO list. Thank you very much! Regards Sven -- 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