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]" 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: 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> <152f7110-7932-a6db-30fd-afccd63822d4 AT iki DOT fi> <83shxpavlp 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 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.