X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Wiktor S. (wswiktorSP AT Mpoczta DOT fm) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Fwd: A few DJGPP libc.a bugs
Date: Fri, 13 May 2016 23:26:33 +0200
Organization: INTERIA.PL S.A.
Lines: 44
Message-ID: <nh5gqc$kb2$1@usenet.news.interia.pl>
References: <56F8295E DOT 2090401 AT posteo DOT de> <571E403D DOT 8080709 AT iki DOT fi> <571E4A50 DOT 3010806 AT iki DOT fi> <571E8166 DOT 1000103 AT gmx DOT de> <571EE412 DOT 6000005 AT iki DOT fi> <CAA-ihx914xS1qBNrR0Uii-jEm_-Q99LtbWHGmbjRj=azqidnaA AT mail DOT gmail DOT com> <152f7110-7932-a6db-30fd-afccd63822d4 AT iki DOT fi> <ngtd8c$vli$1 AT usenet DOT news DOT interia DOT pl> <83shxpavlp DOT fsf AT gnu DOT org> <nh09kj$s6h$1 AT usenet DOT news DOT interia DOT pl> <83zirvajs4 DOT fsf AT gnu DOT org>
NNTP-Posting-Host: user-109-243-236-184.play-internet.pl
Mime-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-2";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Trace: usenet.news.interia.pl 1463174797 20834 109.243.236.184 (13 May 2016 21:26:37 GMT)
X-Complaints-To: usenet AT firma DOT interia DOT pl
NNTP-Posting-Date: Fri, 13 May 2016 21:26:37 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Bytes: 2629
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

> So I think some of this logic doesn't work with exFat volumes, the
> question is which one?  E.g., I'm not sure exFAT support SFN as we
> expect.

Okay. I've made some testing.

I wrote the tests in real-mode assembly (NASM+WLINK) and ran them on Windows 
XP (with exFAT update) and Windows 10. The results were the same.
And surprising :-)

First, what works with exFAT as expected:

- SFN calls to files with short names and paths succeed.
- LFN calls to all files (short or long names) succeed.

So far so good. Now what doesn't work:

- AX=7160h/CL=1/INT21h call, which is supposed to convert long names to 
short ones, SUCCEEDS.

  However, the returned name is LONG. O_o

  e.g. for "f:\foo.example\..\longfilename.txt" it returns 
"f:\longfilename.txt"

- as a result, subsequent SFN call with this "unshort" name fails.


Because AX=7160h can no longer be trusted to return a short name, I see two 
solutions:

A. like mentioned in previous posts, fallback to LFN if SFN call failed.
B. parse the result of 7160h call and check if it is really a short name. 
Use SFN or LFN call accordingly.




-- 
Wiktor S.


"f:\foo.example\..\longfilename.txt"