Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Tue, 17 Feb 2004 17:48:17 -0500
From: "Pierre A. Humblet" <pierre.humblet@ieee.org>
To: cygwin@cygwin.com
Subject: Re: New snapshot available which *may* fix unzip long filenames problem
Message-ID: <20040217224817.GA91611@Worldnet>
References: <20040217201833.GA26980@redhat.com> <20040217205652.GA314375@Worldnet> <20040217210628.GB27861@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040217210628.GB27861@redhat.com>
User-Agent: Mutt/1.4.1i

On Tue, Feb 17, 2004 at 04:06:28PM -0500, Christopher Faylor wrote:
> On Tue, Feb 17, 2004 at 03:56:52PM -0500, Pierre A. Humblet wrote:

> >Good plan. After looking into it, I now think we could get rid of the
> >normalized path storage entirely. It's mostly used in get_name(), which is
> >90% for printf(). A large part of the remaining 10% could use
> >get_win32_name instead (and be faster). A few oddball cases need to be
> >looked into.
> 
> Using the win32_name causes strange side effects.  A win32 name is not
> always equivalent to a unix name.  You lose state.  I just fixed a
> problem with this in stat recently.  I initially fixed it by using the
> unix name but then correctly fixed it by passing the fhandler pointer
> around since that ended up doing many operations only once.
> 
> Eventually, moving everything to use fhandler_* could get rid of a
> requirement to store names at all, although we probably still want to
> keep the win32 name.

Obviously you have thought about it more than I have!
I had in mind the case of the fhandler_*. There are only two other cases
where PC_POSIX is used in path_conv anyway, so they can be taken care of 
individually. I agree that win32 names will remain needed. 
When you have a minute or two, could you think of an example where the 
win32 name would have problems replacing the unix name in fhandler_*?

Pierre

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