X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
	autolearn=disabled version=3.3.2
Date: Thu, 12 May 2016 09:10:35 +0300
Message-Id: <83zirvajs4.fsf@gnu.org>
From: "Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To: djgpp AT delorie DOT com
In-reply-to: <nh09kj$s6h$1@usenet.news.interia.pl> (djgpp@delorie.com)
Subject: Re: Fwd: A few DJGPP libc.a bugs
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>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "Wiktor S. (wswiktorSP AT Mpoczta DOT fm) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
> Date: Wed, 11 May 2016 23:53:20 +0200
> 
> > 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.

If we have problems with 'oflag' passed to '_open', this problem
probably cannot be solved at all, or at least not easily.  So I
suggest to explore the other possibilities first.

> 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.

That logic is as follows:

  . If we are on NT family of Windows (which is your case), then:
    . Produce the short 8+3 alias (SFN) of the long file name (LFN)
    . If producing SFN succeeded, then:
      . Open the file by its SFN
    . Otherwise get file's attributes by its LFN
    . If getting file's attributes succeeds, try opening by LFN, but
      using the SFN variant of DOS OPEN function
    . Otherwise, fail

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.

Thanks.