NetBSD Problem Report #6756

Received: (qmail 24975 invoked from network); 7 Jan 1999 15:31:26 -0000
Message-Id: <19990107153910.25107@wau.mis.ah.nl>
Date: Thu, 7 Jan 1999 15:39:10 +0100
From: Leo Weppelman <leo@wau.mis.ah.nl>
To: gnats-bugs@gnats.netbsd.org
Subject: Re: port-atari/6576: Problem with GEMDOS filenames containing '+'
References: <199812131508.KAA00301@seki.bernstein.com>

>Number:         6756
>Category:       port-atari
>Synopsis:       Re: port-atari/6576: Problem with GEMDOS filenames containing '+'
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-atari-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 07 07:35:01 +0000 1999
>Closed-Date:    Tue Mar 30 11:47:41 +0000 1999
>Last-Modified:  Tue Mar 30 11:49:52 +0000 1999
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->port-atari-maintainer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Mon Mar 15 20:56:42 PST 1999 
Responsible-Changed-Why:  
this is the responsibility of hte port-atari pormaster. 
State-Changed-From-To: open->closed 
State-Changed-By: leo 
State-Changed-When: Tue Mar 30 03:47:41 PST 1999 
State-Changed-Why:  
Because I finally managed to attach all info to pr-6576 where is was 
>Unformatted:
 Per discussion with Wolfgang, the following actions will be taken:

 Short term solution:
    add the '+' (0x2b) entry to the unix2dos table

 --> This solution will be committed.

 About the long-term solution:

 ws@netbsd.org wrote:
 > leo@netbsd.org wrote:
 > > ws@netbsd.org wrote:
 > >
 > > Hmm, I thought more along the lines of dropping the unix2dosfn from lookup
 > > and calling a new function (call it dosfncmp) which gets the pathname to
 > > lookup and the dos directory entry and does the equivalent of calling
 > > dos2unixfn on the entry and comparing the result.  Better yet, try
 > > comparing the unix name to the directory entry a char at a time which
 > > might allow even more exotic names to match...
 > 
 > This might be a significant slowdown... An optimization might be to first
 > try munging the name and see if it has changed. If this is not the case,
 > you can skip the 'expensive' method and use the current one...

 Hmm, I don't think that this would "be a significant slowdown".  While your
 idea probably has some merits, I don't think that it does make a measurable
 difference.

Home	PR Database Search