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@cygwin.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/
