Date: Mon, 01 Oct 2001 12:57:23 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: wojciech DOT galazka AT polkomtel DOT com DOT pl
Message-Id: <9003-Mon01Oct2001125723+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com
In-reply-to: <250B3114DA16D511B82C00E0094005F8023FC1BC@MSGWAW11> (message from
	=?iso-8859-2?Q?Wojciech_Ga=B3=B1zka?= on Mon, 1 Oct 2001 10:19:33
	+0200)
Subject: Re: mntent problem summary on Win2K/XP
References:  <250B3114DA16D511B82C00E0094005F8023FC1BC AT MSGWAW11>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: =?iso-8859-2?Q?Wojciech_Ga=B3=B1zka?= <wojciech DOT galazka AT polkomtel DOT com DOT pl>
> Date: Mon, 1 Oct 2001 10:19:33 +0200 
> 
> > I'd say let's not look for volume labels at all if DOS version is
> > 0x532 and LFN is ON.  I.e. let's make a local change in getmntent.
> > 
> it does work under W2K + LFN, so it's findfirst that's broken

Correction: not findfirst, the DOS function it calls is broken (or at
least that's what we think now).

There's a difference: if findfirst uses wrong code, we can fix it.
But we cannot fix the OS.  findfirst is documented as a direct
interface to the appropriate OS function, so it's okay for it to have
the same misfeatures as the underlying OS.

If we can find a workaround that makes findfirst DTRT even though the
OS doesn't, and that workaround doesn't punish the user unnecessarily,
then let's use that workaround.  But it doesn't make sense IMHO to
cause a single findfirst call to loop until it exhausts all the files,
just to have df display something more interesting that "Drive X:".