delorie.com/archives/browse.cgi | search |
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 |
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"
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |