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:	Wed, 11 May 2016 23:53:20 +0200
Organization:	INTERIA.PL S.A.
Lines:	29
Message-ID:	<nh09kj$s6h$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>
NNTP-Posting-Host:	user-109-243-236-184.play-internet.pl
Mime-Version:	1.0
X-Trace:	usenet.news.interia.pl 1463003604 28881 109.243.236.184 (11 May 2016 21:53:24 GMT)
X-Complaints-To:	usenet AT firma DOT interia DOT pl
NNTP-Posting-Date:	Wed, 11 May 2016 21:53:24 +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:	2330
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

> Can you debug the libc functions involved and see which one of them
> fails?

fopen() fails because open() fails because _open() fails.

I haven't yet determined why. I have two theories.
One is this (abbreviated) logic in open.c:

    fd = _open(real_name, oflag);

 /* Under multi-taskers, such as Windows, our file might be
    open by some other program with DENY-NONE sharing bit,
    which fails the `_open' call above.  Try again with
    DENY-NONE bit set, unless some sharing bits were already
    set in the initial call.  */

    if (fd == -1)
       fd = _open(real_name, oflag | SH_DENYNO);

Both calls to _open() fail. So maybe there is a problem with access flags.

Another possibility is _open function itself. It contains convoluted logic 
of OS version checking, detecting LFN, falling back to SFN, then falling 
back to LFN again...
Perhaps some assumptions are no longer true on exFAT and Windows 10.

-- 
Wiktor S.

- Raw text -