This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stat() and tilde prefix (was bad bash tab completion)


On Feb  7 17:10, Thomas Wolff wrote:
> Am 07.02.2013 16:30, schrieb Eric Blake:
> >...
> >
> >...
> >the fact that cygwin's handling of .. is not POSIX-compliant.  I think a
> >better fix would be to change file_exists() itself instead of adding a
> >misnamed wrapper function; then bashline.c wouldn't even need patching.
> >  The string 'tilde' need not even be in the patch; what you are really
> >after is a function that says that if '..' is found within a string
> >being probed for existence, then add an additional check to see if the
> >prefix of that string exists as a directory.
> >
> >But I don't mind experimenting with the idea - it remains to be seen
> >whether people will complain that bash is noticeably slower because it
> >takes time to double-check instead of rely on cygwin's non-POSIX
> >shortcut.  And the slowdown would only be on paths containing a '..'; I
> >would NOT be checking for symlinks (even though symlinks containing ..
> >are also being interpreted in a non-POSIX manner, it is much more
> >expensive to second-guess if you have to check every name for being a
> >symlink than it is to just check for literal ..).
> Do I interpret correctly that you talk about bash filename completion here?
> Referring to http://cygwin.com/ml/cygwin/2013-01/msg00201.html,
> I'd like to point out that while this ".." thing is a cygwin bug, or
> known downside as Corinna says,
> the same issue occurs on Linux precisely with filename completion
> which isn't consistent there either.
> So it would be "over-fixing" to handle that specifically in bash.
> 
> On the other hand, considering again this "downside":
> If the core cygwin filesystem function would follow this approach,
> simply checking for an occurrence of ".." first before resolving the
> filename,
> wouldn't that be an acceptable fix without inappropriate penalty?

You don't know what you're asking for (can of worms, etc.)

This is some kind of chicken egg problem.

- The path must be normalized, otherwise we can't reliably convert
  the POSIX path prefix to a Windows pathname.

- Only after converting to a Windows path, we can perform file checks.

- Rinse and repeat.

Also, the path normalization is performed in an entirely distinct
function from the mount point conversion, and this in turn is another
function than the path function handling symlinks and devices.
Changing that requires to implement the path conversion functionality
almost from scratch.  Given the age of some of these functions, I'd
like to have done that for a long time, but I'm constantly shying away
since I don't want to break what is working today.  There's, of course,
still the aforementioned chicken-egg problem.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]