Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 22 Aug 2005 15:31:58 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Path processing bug
Message-ID: <20050822133158.GD17452@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20050822002413 DOT GE12465 AT trixie DOT casa DOT cgf DOT cx> <20050822025905 DOT 7896213C83C AT cgf DOT cx> <20050822031715 DOT GA17547 AT trixie DOT casa DOT cgf DOT cx> <4309C7D6 DOT 5070906 AT byu DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4309C7D6.5070906@byu.net>
User-Agent: Mutt/1.4.2i

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/