Date: Mon, 15 Oct 2001 10:48:09 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc: djgpp-workers AT delorie DOT com
Subject: Re: W2K/XP fncase
In-Reply-To: <10110150338.AA16562@clio.rice.edu>
Message-ID: <Pine.SUN.3.91.1011015104611.23336B@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Sun, 14 Oct 2001, Charles Sandmann wrote:

> id83 /.../*
> which globs all files on the disk and then tests the names.  I'd be
> interested if anyone who runs it on a non-W2K/XP system finds any
> differences.  It takes a long time on big disks just to complete the
> glob.
> 
> The test program compares the behavior to the strcmp(_lfn_gen_...) combo.
> On my Win95 system it found one difference, a DOS game copy protection
> file which contains a space.

In my case, it tried more than 85,000 files and found no differences.

Note that, as written, the program will not try hidden files because
`glob' ignores them when expanding wildcards.

Btw, it took the program 0.94 seconds to run its main loop, which is
about 11 microseconds per file name.  Even if we assign all this time
to _lfn_gen_short_fname and strcmp that uses its result, 11 usec per
call is a negligible amount of time, I think.  (This is on a 866-MHz
Pentium III.)  For comparison, the elapsed time for running the
program was 30 minutes, with all but the last second used up by
`glob's expansion of "/.../*".

> char _is_DOS83(const char *fname)

I suggest to have this return an int instead.

> {
>   const char *s = fname;
>   const char *e;
>   char c, period_seen;
> 
>   if(*s == '.')			/* starting period invalid */
>     return 0;

This will do the wrong thing with "." and ".." (if the function is to
be used for something other than just the decision on whether to
downcase; the function's name suggests that it's supposed to tell
whether the argument is a valid DOS file name).

>     else if (c == '+' || c == ',' || c == ';' || 
>              c == '=' || c == '[' || c == ']')

I think this should include a blank.

> Further testing on DH=1 for 71A8 on 2K/XP found some potential work arounds, 
> then several more new problems.  In a nutshell, if the first part of the file
> name has 1 or 2 characters, you get bogus results.  It will usually
> give correct values for 3,4,5,6 characters.  It will always truncate 
> characters 7,8.  So LICENSE.TXT becomes LICENS.TXT.  Yes, it's hopeless.
> Yes, it truncates to 6.3 for DH=0 also.  I think the NT code must have
> been written by an old Digital RT-11 programmer since their file system
> was 6.3...

No, I think this gives a good clue about the nature of the bug.  They
generate only the first 6 characters because the other two are the ~N
numeric tail  Because of that, they have a bug when the part before the 
period has 2 or less characters, probably because they do "len - 2", 
which gives a negative number.

It's a beginner's bug, and the function was probably never tested on a
real filesystem.

> I don't see any way to fix this other than:
> 1) Document it's trash and advise no one to use it, or
> 2) Insert emulation code if os=2K/XP inside it.

We should at least document this.  I think we should also file a bug
report with Microsoft; it's a disgrace for their QA to let such bugs
into the open.