Mail Archives: cygwin/2018/06/13/04:36:05
> Gesendet: Dienstag, 12. Juni 2018 um 18:28 Uhr
> Von: "Brian Inglis" <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
> On 2018-06-12 07:14, Sven Eden wrote:
> >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr
> >> Von: "Eric Blake" <eblake AT redhat DOT 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
- Raw text -