Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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:	Tue, 17 Feb 2004 15:56:52 -0500
From:	"Pierre A. Humblet" <pierre DOT humblet AT ieee DOT org>
To:	cygwin AT cygwin DOT com
Subject:	Re: New snapshot available which *may* fix unzip long filenames problem
Message-ID:	<20040217205652.GA314375@Worldnet>
References:	<20040217201833 DOT GA26980 AT redhat DOT com>
Mime-Version:	1.0
In-Reply-To:	<20040217201833.GA26980@redhat.com>
User-Agent:	Mutt/1.4.1i

On Tue, Feb 17, 2004 at 03:18:33PM -0500, Christopher Faylor wrote:
> I've created a new snapshot which incorporates Pierre's much appreciated
> research into the unzip problem.
> 
> Thanks to Pierre and Igor for looking into things at this depth.
> 
> I'm rather torn between fixing build_fh_name and keeping the destructor.
> The destructor is cleaner but slower and its in a part of the code that
> gets called *a lot*.
> 
> If it works, I'll probably keep the destructor around for 1.5.8 and
> revisit in some later cygwin version.

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.

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/

- Raw text -