> Gesendet: Dienstag, 12. Juni 2018 um 19:56 Uhr > Von: "Eric Blake" <ebl...@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
