* Problematic interpretion of paths starting with double slashes @ 2018-06-12 11:45 Sven Eden 2018-06-12 11:52 ` Adam Dinwoodie 2018-06-12 16:28 ` Eric Blake 0 siblings, 2 replies; 16+ messages in thread From: Sven Eden @ 2018-06-12 11:45 UTC (permalink / raw) To: cygwin Hello everybody, I have a problem with a script that wants to copy a file, which has a variable paths build from various variables. The first variable is a possible prefix, the second an absolute path. If no prefix is needed, the first consists of just a slash. What I now see is the following: -------- # 09:29:17 SEden@CHH0711 ~ > rm -rf /tmp/foo # 09:29:37 SEden@CHH0711 ~ > mkdir -p /tmp/foo # 09:29:42 SEden@CHH0711 ~ > touch /tmp/foo/bar # 09:29:59 SEden@CHH0711 ~ > cp //tmp/foo/bar /tmp/foo/baz cp: cannot stat '//tmp/foo/bar': No such file or directory -------- This puzzled me, because this works perfectly well on every GNU/Linux (plus WSL) system I tried. Actually it is completely in order to double any slashes. This behavior breaks quite some Makefiles... I am completely aware that §4.13 of the Open Group Base Specification Issue 7 (IEEE Std 1003.1-2017) reads: "If a pathname begins with two successive <slash> characters, the first component following the leading <slash> characters may be interpreted in an implementation-defined manner, although more than two leading <slash> characters shall be treated as a single <slash> character." 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? On any Linux system, 'stat -c "%i" / //' would show the same inode number twice: -------- stat -c "%2n %f %i" / // / 41ed 48976645948727610 // 41ed 48976645948727610 -------- On Cygwin we get: -------- stat -c "%2n %f %i" / // / 41ed 4222124652325260 // 416d 18014896789143535314 -------- I have searched the cygwin mailing list, but all I could find was some discussion about UNC paths from 1997. So, what do you think? Sincerely Sven P.S An example of a failing script line is: https://github.com/gentoo/gentoo/blob/331976f/eclass/toolchain.eclass#L2136 -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problematic interpretion of paths starting with double slashes 2018-06-12 11:45 Problematic interpretion of paths starting with double slashes Sven Eden @ 2018-06-12 11:52 ` Adam Dinwoodie 2018-06-12 16:28 ` Eric Blake 1 sibling, 0 replies; 16+ messages in thread From: Adam Dinwoodie @ 2018-06-12 11:52 UTC (permalink / raw) To: cygwin On Tue, 12 Jun 2018 at 09:53, Sven Eden wrote: > I have a problem with a script that wants to copy a file, > which has a variable paths build from various variables. > > The first variable is a possible prefix, the second an > absolute path. If no prefix is needed, the first consists of > just a slash. > > What I now see is the following: > > -------- > # 09:29:17 SEden@CHH0711 ~ > > rm -rf /tmp/foo > > # 09:29:37 SEden@CHH0711 ~ > > mkdir -p /tmp/foo > > # 09:29:42 SEden@CHH0711 ~ > > touch /tmp/foo/bar > > # 09:29:59 SEden@CHH0711 ~ > > cp //tmp/foo/bar /tmp/foo/baz > cp: cannot stat '//tmp/foo/bar': No such file or directory This is intended behaviour. Cygwin interprets paths starting with // as being attempts to access a UNC path; //tmp/foo/bar is an attempt to access the file/directory "bar" in the "foo" share on the networked machine "tmp", in the same way as attempting to access \\tmp\foo\bar from a Windows cmd console or similar. This is documented at <https://cygwin.com/cygwin-ug-net/using.html#unc-paths>. Here, Cygwin isn't attempting to emulate Linux, which, as you note, generally considers a double forward slash at the start of a path as identical to a single slash. Instead, Cygwin, like Linux, is an implementation of the POSIX standards. POSIX states "A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner", so Cygwin is being POSIX-compliant here, per <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11> I think it's very unlikely Cygwin is going to change its behaviour here; this is documented and well-understood behaviour that other Cygwin users – myself included – are going to be relying on. If you want to be able to use your scripts on Cygwin as well as Linux systems, you'll need to update them to not rely on implementation-specific behaviour that can vary between POSIX implementations. (I could believe you could get buy-in for ways to change the // behaviour that wouldn't change behaviour for existing users, e.g. by basing it on setting the CYGWIN environment variable per <https://cygwin.com/cygwin-ug-net/using-cygwinenv.html>, or possibly something with the mount table per <https://cygwin.com/cygwin-ug-net/using.html#using-pathnames>. However I've no idea whether that would be possible without unacceptable compromises to performance or similar, and as ever someone has to volunteer the time to do it.) Adam -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problematic interpretion of paths starting with double slashes 2018-06-12 11:45 Problematic interpretion of paths starting with double slashes Sven Eden 2018-06-12 11:52 ` Adam Dinwoodie @ 2018-06-12 16:28 ` Eric Blake 2018-06-12 17:12 ` Aw: " Sven Eden 1 sibling, 1 reply; 16+ messages in thread From: Eric Blake @ 2018-06-12 16:28 UTC (permalink / raw) To: cygwin, sven.eden On 06/12/2018 03:53 AM, Sven Eden wrote: > Hello everybody, > > I have a problem with a script that wants to copy a file, > which has a variable paths build from various variables. > > The first variable is a possible prefix, the second an > absolute path. If no prefix is needed, the first consists of > just a slash. Then fix your script to provide 3 slashes instead of 2. Only 2 slashes has the magic UNC behavior. 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} to get portable behavior that always resolves to the root dir instead of trying to dereference remote machines under //. > > This puzzled me, because this works perfectly well on every > GNU/Linux (plus WSL) system I tried. Just because your script "works" on a number of systems doesn't mean it is portable. > I am completely aware that §4.13 of the Open Group Base > Specification Issue 7 (IEEE Std 1003.1-2017) reads: > "If a pathname begins with two successive <slash> > characters, the first component following the leading > <slash> characters may be interpreted in an > implementation-defined manner, although more than two > leading <slash> characters shall be treated as a single > <slash> character." Yes, that's exactly why your script is not portable. So even though Linux has chosen to make "/" and "//" synonymous, Cygwin has not. > > 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. Better is to fix your script to not try accessing '//tmp' in the first place. > 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. > P.S An example of a failing script line is: > https://github.com/gentoo/gentoo/blob/331976f/eclass/toolchain.eclass#L2136 Well, then report that as a bug to the author of that script. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Aw: Re: Problematic interpretion of paths starting with double slashes 2018-06-12 16:28 ` Eric Blake @ 2018-06-12 17:12 ` Sven Eden 2018-06-12 17:57 ` Brian Inglis ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Sven Eden @ 2018-06-12 17:12 UTC (permalink / raw) To: cygwin > Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr > Von: "Eric Blake" <eblake@redhat.com> > 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. > 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? > > 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. > > 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? 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problematic interpretion of paths starting with double slashes 2018-06-12 17:12 ` Aw: " Sven Eden @ 2018-06-12 17:57 ` Brian Inglis 2018-06-13 10:14 ` Aw: " Sven Eden 2018-06-12 20:01 ` Aw: " Eric Blake ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: Brian Inglis @ 2018-06-12 17:57 UTC (permalink / raw) To: cygwin On 2018-06-12 07:14, Sven Eden wrote: >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr >> Von: "Eric Blake" <eblake@redhat.com> >> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Aw: Re: Problematic interpretion of paths starting with double slashes 2018-06-12 17:57 ` Brian Inglis @ 2018-06-13 10:14 ` Sven Eden 2018-06-13 13:49 ` Andrey Repin 2018-06-15 2:41 ` Brian Inglis 0 siblings, 2 replies; 16+ messages in thread From: Sven Eden @ 2018-06-13 10:14 UTC (permalink / raw) To: cygwin > Gesendet: Dienstag, 12. Juni 2018 um 18:28 Uhr > Von: "Brian Inglis" <Brian.Inglis@SystematicSw.ab.ca> > On 2018-06-12 07:14, Sven Eden wrote: > >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr > >> Von: "Eric Blake" <eblake@redhat.com> > >> 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problematic interpretion of paths starting with double slashes 2018-06-13 10:14 ` Aw: " Sven Eden @ 2018-06-13 13:49 ` Andrey Repin 2018-06-15 2:41 ` Brian Inglis 1 sibling, 0 replies; 16+ messages in thread From: Andrey Repin @ 2018-06-13 13:49 UTC (permalink / raw) To: Sven Eden, cygwin Greetings, Sven Eden! >> Gesendet: Dienstag, 12. Juni 2018 um 18:28 Uhr >> Von: "Brian Inglis" <Brian.Inglis@SystematicSw.ab.ca> >> On 2018-06-12 07:14, Sven Eden wrote: >> >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr >> >> Von: "Eric Blake" <eblake@redhat.com> >> >> 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. ;-) If it is documented, it is not wrong. > 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 Can? Yes. Purely technically. But for consistency it will not be. Ambiguous paths are a big no-no. -- With best regards, Andrey Repin Wednesday, June 13, 2018 15:48:59 Sorry for my terrible english... -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problematic interpretion of paths starting with double slashes 2018-06-13 10:14 ` Aw: " Sven Eden 2018-06-13 13:49 ` Andrey Repin @ 2018-06-15 2:41 ` Brian Inglis 1 sibling, 0 replies; 16+ messages in thread From: Brian Inglis @ 2018-06-15 2:41 UTC (permalink / raw) To: cygwin On 2018-06-13 02:34, Sven Eden wrote: > 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? Look at: https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob_plain;f=winsup/cygwin/fhandler_netdrive.cc;hb=HEAD -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Aw: Re: Problematic interpretion of paths starting with double slashes 2018-06-12 17:12 ` Aw: " Sven Eden 2018-06-12 17:57 ` Brian Inglis @ 2018-06-12 20:01 ` Eric Blake 2018-06-13 13:05 ` Sven Eden 2018-06-12 20:32 ` Lee 2018-06-12 23:31 ` Aw: " Achim Gratz 3 siblings, 1 reply; 16+ messages in thread From: Eric Blake @ 2018-06-12 20:01 UTC (permalink / raw) To: cygwin, sven.eden On 06/12/2018 08:14 AM, Sven Eden wrote: >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr >> Von: "Eric Blake" <eblake@redhat.com> >> 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. Good to know! > > >> 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. Good style is nice, but in my book, it is trumped by correct code. Since three slashes always behaves identically to one slash, it's handy to know that bending style gets you a construct where you no longer have to worry about what the user may have passed in through variables, even if it is stylistically a bit more verbose than a form that uses minimal /. > > >> 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? 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. > > >>> 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, ...). > > >>> 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. Yes, you've got that part right. > > 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? Yes. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problematic interpretion of paths starting with double slashes 2018-06-12 20:01 ` Aw: " Eric Blake @ 2018-06-13 13:05 ` Sven Eden 0 siblings, 0 replies; 16+ messages in thread From: Sven Eden @ 2018-06-13 13:05 UTC (permalink / raw) To: cygwin > Gesendet: Dienstag, 12. Juni 2018 um 19:56 Uhr > Von: "Eric Blake" <eblake@redhat.com> > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Re: Problematic interpretion of paths starting with double slashes 2018-06-12 17:12 ` Aw: " Sven Eden 2018-06-12 17:57 ` Brian Inglis 2018-06-12 20:01 ` Aw: " Eric Blake @ 2018-06-12 20:32 ` Lee 2018-06-13 13:05 ` Aw: " Sven Eden 2018-06-12 23:31 ` Aw: " Achim Gratz 3 siblings, 1 reply; 16+ messages in thread From: Lee @ 2018-06-12 20:32 UTC (permalink / raw) To: cygwin On 6/12/18, 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. but it was portable > Good style is to guarantee, that > not more than one slash is issued. Why don't you submit a patch to guarantee that not more than one slash is issued? Or submit a bug report that the earlier patch broke portability? Asking cygwin to change their long standing, posix allowed, implementation defined behavior seems like the least likely way to get the problem fixed. Regards, Lee -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Aw: Re: Re: Problematic interpretion of paths starting with double slashes 2018-06-12 20:32 ` Lee @ 2018-06-13 13:05 ` Sven Eden 0 siblings, 0 replies; 16+ messages in thread From: Sven Eden @ 2018-06-13 13:05 UTC (permalink / raw) To: cygwin > Gesendet: Dienstag, 12. Juni 2018 um 20:02 Uhr > Von: Lee <ler762@gmail.com> > On 6/12/18, Sven Eden wrote: > > Good style is to guarantee, that > > not more than one slash is issued. > > Why don't you submit a patch to guarantee that not more than one slash > is issued? Already done. > Or submit a bug report that the earlier patch broke portability? Already done. > Asking cygwin to change their long standing, posix allowed, > implementation defined behavior seems like the least likely way to get > the problem fixed. I never did that. All I did was to ask whether such an extension would be possible. It is, so my question is answered. And btw., the implementation, if extended in the way I proposed, would still be POSIX compliant. ;-) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Aw: Re: Problematic interpretion of paths starting with double slashes 2018-06-12 17:12 ` Aw: " Sven Eden ` (2 preceding siblings ...) 2018-06-12 20:32 ` Lee @ 2018-06-12 23:31 ` Achim Gratz 2018-06-13 9:57 ` Corinna Vinschen 3 siblings, 1 reply; 16+ messages in thread From: Achim Gratz @ 2018-06-12 23:31 UTC (permalink / raw) To: cygwin Sven Eden writes: > 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.) Well, it does break things if both //this/or/that /this/or/that exist and then at some point host "this" becomes unreachable. So I'd keep //unc/path to mean just that on principle. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Aw: Re: Problematic interpretion of paths starting with double slashes 2018-06-12 23:31 ` Aw: " Achim Gratz @ 2018-06-13 9:57 ` Corinna Vinschen 2018-06-13 13:29 ` Sven Eden 0 siblings, 1 reply; 16+ messages in thread From: Corinna Vinschen @ 2018-06-13 9:57 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 925 bytes --] On Jun 12 22:01, Achim Gratz wrote: > Sven Eden writes: > > 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.) > > Well, it does break things if both > > //this/or/that > /this/or/that > > exist and then at some point host "this" becomes unreachable. So I'd > keep //unc/path to mean just that on principle. ACK Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problematic interpretion of paths starting with double slashes 2018-06-13 9:57 ` Corinna Vinschen @ 2018-06-13 13:29 ` Sven Eden 2018-06-13 19:32 ` Achim Gratz 0 siblings, 1 reply; 16+ messages in thread From: Sven Eden @ 2018-06-13 13:29 UTC (permalink / raw) To: cygwin > Gesendet: Mittwoch, 13. Juni 2018 um 10:09 Uhr > Von: "Corinna Vinschen" <corinna-cygwin@cygwin.com> > On Jun 12 22:01, Achim Gratz wrote: > > Sven Eden writes: > > > 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.) > > > > Well, it does break things if both > > > > //this/or/that > > /this/or/that > > > > exist and then at some point host "this" becomes unreachable. So I'd > > keep //unc/path to mean just that on principle. > > ACK > True, if /this isn't just a mount point for //this, meaning that the "that"s are two different files. Apart from the urge to question the sanity of anybody setting something up like that, I see that this is a serious objection to consider. I mean, seriously, something like that *is* prone to typos, and whoever does that will end up manipulating/using the wrong file rather often anyway. Which leads to the point that such a setup makes injecting not mounted network shares like that quite dangerous... Just my thoughts... Doesn't matter anymore anyway, as my main question of interest was answered. ;-) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Problematic interpretion of paths starting with double slashes 2018-06-13 13:29 ` Sven Eden @ 2018-06-13 19:32 ` Achim Gratz 0 siblings, 0 replies; 16+ messages in thread From: Achim Gratz @ 2018-06-13 19:32 UTC (permalink / raw) To: cygwin Sven Eden writes: > True, if /this isn't just a mount point for //this, meaning > that the "that"s are two different files. […] Again, my main objection is that the interpretation of a path should not change based on the availability or non-availability of any host (or its name resolution) over the network. That's exactly the kind of thing that will come back to bite you in the most inconvenient moment. Regarding the discussion about Linux behaviour, I'd be happy if Linux had an option to just make any path with two leading slashes throw an error if that path makes it anywhere a local filesystem gets involved. That'd be quite helpful in quickly weeding out portability problems like the one you showed. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-06-14 17:41 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-06-12 11:45 Problematic interpretion of paths starting with double slashes Sven Eden 2018-06-12 11:52 ` Adam Dinwoodie 2018-06-12 16:28 ` Eric Blake 2018-06-12 17:12 ` Aw: " Sven Eden 2018-06-12 17:57 ` Brian Inglis 2018-06-13 10:14 ` Aw: " Sven Eden 2018-06-13 13:49 ` Andrey Repin 2018-06-15 2:41 ` Brian Inglis 2018-06-12 20:01 ` Aw: " Eric Blake 2018-06-13 13:05 ` Sven Eden 2018-06-12 20:32 ` Lee 2018-06-13 13:05 ` Aw: " Sven Eden 2018-06-12 23:31 ` Aw: " Achim Gratz 2018-06-13 9:57 ` Corinna Vinschen 2018-06-13 13:29 ` Sven Eden 2018-06-13 19:32 ` Achim Gratz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).