X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:reply-to:subject:to:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=Pd9SMtxH1x7WmRIx 6jJGWq3zfuDXUU/yzIRxpGa+gPybijaJpdDubsk4mtkOi0XuN6CBOB9RxmexofHq a5W0j9EhTpIbmbzc8bmN/1Pg+wpObVWpDpIgC1JujBRu6zjYpiHh1rFCDmdDu11T R5kDooonZRp1G3DAeUwqpkSxH0g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:reply-to:subject:to:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=KXlNMQJZ4zUmVYWs3Lgj0s IP0mo=; b=uR+TZ9XzvsWF6zkVMwZj69fAzS2ka0jCsZoBkA6P/tyKkxTce7GMJc //0nSFcVBOR39sYiXWhSveL8qg9dR80M+gliEr40VxdZiV1dSIn3xIt4DFxuDMMn 2LHPtCPlN76g5QT3+FWjdV4VIPz5KSDzITNoSfCNVmSdDkqOIALBg= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Single, H*UA:10.0, H*u:10.0, H*Ad:D*ab.ca X-HELO: smtp-out-no.shaw.ca X-Authority-Analysis: v=2.3 cv=PvS9kTE3 c=1 sm=1 tr=0 a=MVEHjbUiAHxQW0jfcDq5EA==:117 a=MVEHjbUiAHxQW0jfcDq5EA==:17 a=IkcTkHD0fZMA:10 a=20KFwNOVAAAA:8 a=EJsovmrbzapQHRGv3oYA:9 a=UpCUsghKHMFbxk1L:21 a=waWMMazKQHSPVqCs:21 a=QEXdDO2ut3YA:10 Reply-To: Brian DOT Inglis AT SystematicSw DOT ab DOT ca Subject: Re: Problematic interpretion of paths starting with double slashes To: cygwin AT cygwin DOT com References:

From: Brian Inglis Openpgp: preference=signencrypt Message-ID: <00de90b8-a2b4-f751-1ef2-05645a3f1119@SystematicSw.ab.ca> Date: Tue, 12 Jun 2018 10:28:52 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfL/O04XxrFn1Dc8bHNrBh8Mce7Aggr4LdpyvJScNv9BNKHBV9tqGJ18P+r7/Jx4tutF7H+4OwC32Zg4xsYUoqE2JjmwYGXhR4IHzWhlU7+PdBppgK9aR 2s4uwMj8CZumUk7ZEB9dtqe3t49Asekb0r8mw0cOf6Xn46N7ENd8QhCltowBXEsYFmC5umkZ5ndBMw== X-IsSubscribed: yes 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". >> 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" ;^> >>> 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. >>> 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: $ for p in / // ///; do time ls ${p}tmp/foo/bar; done ls: cannot access '/tmp/foo/bar': No such file or directory real 0m0.040s user 0m0.015s sys 0m0.030s ls: cannot access '//tmp/foo/bar': No such file or directory real 0m2.333s user 0m0.015s sys 0m0.015s ls: cannot access '///tmp/foo/bar': No such file or directory real 0m0.035s user 0m0.015s sys 0m0.015s -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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