X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10201101617.AA12879@clio.rice.edu>
Subject: Re: LFN32 optimizations [was:  Re: Proposed lstat.c patch for Win2000/XP device bit fix
To: eliz AT is DOT elta DOT co DOT il
Date: Thu, 10 Jan 2002 10:17:20 -0600 (CST)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <2110-Thu10Jan2002091030+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Jan 10, 2002 09:10:30 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> > Date: Wed, 9 Jan 2002 18:31:43 -0600 (CST)
> > 
> > Should we do this fix to access.c also
> 
> Yes, definitely.  The call to findfirst inside access was added
> because there were Unix-born programs (I forget which ones) that
> barfed without it.  We don't need to see them barfing again ;-)

I was actually referring to optimizing the strcmp() check for LFN32.
The findfirst() call in access is for the case where devices fail
_chmod - which I don't believe happens under Win2K.

I am hazy in the remembering now, but I don't think access was
broken.  According to old email, _chmod on devices returns 0x20, so
it looks like a writable normal file - so access should be OK.

> > and a similar fix to set the value in findfirs.c?
> 
> You mean, to set the device bit in attributes?  No, I don't think
> this is needed: not every DOS-like OS sets that attribute anyway.

Actually I meant moving the magic string "LFN32" into two magic values
in dir.h, ie:

#define _ff_LFN_Magic1 ('L'+'F'<<8+'N'<<16+'3'<<24)
#define _ff_LFN_Magic2 ('2'+ 0 <<8)

and using that to set the values in findfirs.c instead of the strcpy.
Those values would also be in the _is_ff_LFN macro.

> > Should a macro _is_ff_LFN(ff_blk) be in dir.h?
> 
> Sounds like a good idea.