Mail Archives: cygwin/2005/08/22/09:32:12
On Aug 22 06:40, Eric Blake wrote:
> How often does the substring /../ actually appear in path name resolution?
> I don't think it is all that often, and the penalty for getting that
> corner case POSIXly correct need not affect the common case when /../ is
> not part of the path name. Besides, the code in path.cc is already doing
> something with /../ or you wouldn't be shortening '/dir/../' to '/'.
There's a function called normalize_posix_path, which tacks the home dir
in from of relative paths and removes . and .. components from the path.
I don't agree with you that /../ components are actually seldom in path
expressions. If you examine typical source trees, you'll find that
expressions as -I../../foo/bar or -L/path/to/bin/../lib are used quite
often.
The problem is that right now, most of these paths are evaluated correctly,
but some aren't, like in the lisp/../xedit.h case where lisp is a symlink.
Actually I'm wondering that we didn't already stumble over this problem
more often.
That to say, I think that Chris isn't saying he's against making the path
handling correct, but the problem is that the path handling is already
quite complex. Handling the aforemention situation correctly would require
the path normalization routine to check each sub path below a /.. component
for existence, which in turn requires symlink expansion etc. As he stated,
>> As always, I can't speak for Corinna, but I suspect that she would be as
>> thrilled as I would be if you fixed this contrary-to-POSIX problem
>> without impacting the speed of cygwin's already slow path handling code.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -