Date: Fri, 23 Mar 2001 13:10:57 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: Martin Str|mberg <ams AT father DOT ludd DOT luth DOT se>
Message-Id: <2110-Fri23Mar2001131056+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp AT delorie DOT com
In-reply-to: <99dikd$ftj$1@news.luth.se> (message from Martin Str|mberg on
	Thu, 22 Mar 2001 19:09:01 +0000 (UTC))
Subject: Re: Freedos, INT 0x21, AX=0x71a0 and emacs
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010322094711 DOT 7564F-100000 AT is> <99cfks$cbt$1 AT antares DOT lu DOT erisoft DOT se> <99dikd$ftj$1 AT news DOT luth DOT se>
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: Martin Str|mberg <ams AT father DOT ludd DOT luth DOT se>
> Newsgroups: comp.os.msdos.djgpp
> Date: Thu, 22 Mar 2001 19:09:01 +0000 (UTC)
> 
> : : This is already done by the library.  Except that, in FreeDOS's case,
> : : I understand that 71A0h doesn't return ENOSYS, so the library thinks
> : : something else went wrong, and doesn't cache the return value.  See
> : : the source of _use_lfn; I think we discussed this a while ago, and you
> : : said the problem is going to be solved in the next release of FreeDOS.
> 
> : Now I'm really confused. Unsupported INT 0x21 calls should set AL to
> : zero according to you and other persons. How is FreeDOS going to be
> : able to set AX to an error value in that case?
> 
> : Hmm... (Digging in the use_lfn() source...) Ok. You mean
> : _get_volume_info() instead 71A0h above returning ENOSYS. I think with
> : the FreeDOS kernel I tried _get_volume_info() really returns ENOSYS
> : (or at least should), but I have to check it.
> 
> Ok, now I've checked and my FreeDOS kernel do make _get_volume_info()
> set errno to ENOSYS and return 0.
> 
> So if I understood you correctly there ought to be bug somewhere (in
> DJGGP or emacs) because there should only one calls to it in that case
> but I see several.

I'm not sure there's a bug; Emacs doesn't do anything that any other
DJGPP program would do.  Please step with a debugger into _use_lfn and
see what happens there.

What you describe can and should happen if 71A0h doesn't return 71h
in the AH register.  In that case, the library function
`_get_volume_info' does this:

    if (r.h.ah == 0x71)
    {
      errno = ENOSYS;
      retval = 0;	/* meaning none of the features supported */
    }
    else
    {
      /* If the call failed, but not because the OS doesn't support
	 the function (e.g., invalid drive), don't disable LFN.  */
      errno = __doserr_to_errno(r.x.ax);
      retval = _FILESYS_UNKNOWN;
    }

If FreeDOS doesn't return 71h in the AH register, this will return
_FILESYS_UNKNOWN.  The function `_use_lfn' then does this:

  if (!same_drive_as_last_time || filesystem_flags == _FILESYS_UNKNOWN)
    filesystem_flags = _get_volume_info (path, 0, 0, 0);

  /* If _get_volume_info failed (e.g., an invalid drive letter),
     leave the previous LFN setting alone.  */
  if (filesystem_flags == _FILESYS_UNKNOWN)
  {
    _lfnenv = old_lfn_flag;
    last_drive = 0;
    return _lfnenv != 'n';
  }

In other words, if `_get_volume_info' returns _FILESYS_UNKNOWN, the
result is not cached for future calls to `_use_lfn', because
`_use_lfn' suspects that the call failed because some problem that is
irrelevant to whether LFN is or isn't supported, e.g. if the drive
letter was invalid.  Instead of caching the result in
filesystem_flags, `_use_lfn' leaves _FILESYS_UNKNOWN there.  This in
turn will cause the next call to `_use_lfn' call `_get_volume_info'
again and again...