Date: Wed, 22 Feb 2006 12:30:34 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: another instance of .. issues
Message-ID: <20060222173034.GA18903@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <022220061600 DOT 18471 DOT 43FC8AA2000A6AE70000482722073007930A050E040D0C079D0A AT comcast DOT net> <43FC8F9C DOT B3308DA8 AT dessent DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43FC8F9C.B3308DA8@dessent.net>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Wed, Feb 22, 2006 at 08:21:48AM -0800, Brian Dessent wrote:
>Eric Blake wrote:
>>and/or have openat() implemented directly in cygwin so that the openat
>>emulation of open("/proc/self/fd/4/..") is avoided (not to mention more
>>efficient by avoiding several other syscalls during the emulation).
>
>I think implementing openat() directly would be the clear win here,
>since the ".." processing seems to be such a landmine.  Of course
>without a patch this is just hot air on my part.

But, then, it has been at least a couple of months since we've had
a rousing discussion about how awful cygwin's '..' handling is, so
it's clearly time to go into great depth about how useful it would
be if cygwin just did things the RIGHT, the TRUE, the POSIX way.

cgf

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