From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69019 invoked by alias); 13 Jun 2018 08:35:54 -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 68563 invoked by uid 89); 13 Jun 2018 08:34:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=wonderful, answered, peoples X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.19) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Jun 2018 08:34:57 +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:34:54 +0200 MIME-Version: 1.0 Message-ID: From: "Sven Eden" To: cygwin@cygwin.com Subject: Aw: Re: Problematic interpretion of paths starting with double slashes Content-Type: text/plain; charset=UTF-8 Date: Wed, 13 Jun 2018 10:14:00 -0000 Sensitivity: Normal In-Reply-To: <00de90b8-a2b4-f751-1ef2-05645a3f1119@SystematicSw.ab.ca> References: <00de90b8-a2b4-f751-1ef2-05645a3f1119@SystematicSw.ab.ca> X-UI-Message-Type: mail X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00139.txt.bz2 > Gesendet: Dienstag, 12. Juni 2018 um 18:28 Uhr > Von: "Brian Inglis" > On 2018-06-12 07:14, Sven Eden wrote: > >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr > >> Von: "Eric Blake" > >> Then fix your script to provide 3 slashes instead of 2. Only 2 slashes > >> has the magic UNC behavior. > > It is not my script. *my* scripts are portable by all means. > >> That is, if you have a script that is concatenating: > >> ${prefix}/${dir} > >> where ${prefix} might be empty, you can always rewrite it to be: > >> ${prefix}///${dir} > > The script was "fixed" from ${prefix}/${dir} a while ago. Before that the > > outcome was "///". Which is very bad style. Good style is to guarantee, that > > not more than one slash is issued. > > Which is equivalent to //localhost/ on Cygwin and elsewhere - / on Linux - this > is semantics not "style". I talked about replacing something wrong with something worse. That's style, not semantics. But I get what you are meaning. ;-) > >> Just because your script "works" on a number of systems doesn't mean it > >> is portable. > > I neither wrote it was my script, nor that it was portable per se. But > > thanks for jumping down my throat for nothing. I won't quote and answer to > > your further attacks, but instead concentrate on the relevant stuff, okay? > > Eric contributes to The Open Group Single Unix Spec and elsewhere and provides > these explanations frequently - that's his "style" ;^> Interpreting claims, that were never made, into other peoples statements is not "style". But that doesn't matter, really. I got his point all right. > >>> 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. > > If you can't fix the target, wrap it with another script or function, and run it > with "command script paths...", so it never sees non-POSIX-compliant paths. That is a wonderful idea. Doesn't work with a package manager as complex as Portage, but its a start. > >>> I have searched the cygwin mailing list, but all I could find was some > >>> discussion about UNC paths from 1997. > >> Yes, we've had special support for // as UNC for a LOOONG time, and > >> changing it now would break existing users that expect it to work as > >> allowed by POSIX. > > Keeping it, changing it, extending it. It doesn't matter. All three variants > > would be fully POSIX compliant. However, I never asked to actually change the > > current behaviour. Only whether it was possible to extend it. > > Looking up // as UNC is the default, wanted and expected behaviour. I got > > that right from the start and even wrote that I find that pretty cool. > > Doing a simple stat on / if (and only if) the UNC lookup fails, does not > > endanger anything. It wouldn't break anything or do any other damage. Besides > > from adding an additional <0.01s lag to any failed access that *really* meant > > a network share. > > So no. Adding this tiny extra functionality wouldn't break anything for > > anybody, but allowed the usage of software that relies on the non-cygwin > > behaviour. (And is outside the users control.) > > Am I right that the relevant stuff can be found in winsup/cygwin? > > Overhead is ~2.5s for non-existent share checks on my system: No. I talked about the overhead to do an extra stat if a regular UNC access attempt fails. The lag on the UNC check is there anyway if you access non-existent //foo/bar. So on my currently idle system the average lag is: $ time for i in $(seq 1 100) ; do stat /foo/bar/$i 2>/dev/null ; done real 0m3,164s user 0m0,817s sys 0m1,120s => ~31ms per request. That can go up on high IO, though. However, from my two questions, one was answered, and I can figure out the other just fine by myself. Q: Can the handling of // be extended to check for / if the first fails? A: Yes Unanswered: Is the relevant stuff to be found in winsup/cygwin? Thank you very much for your patience and support. Cheers 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