From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10110011332.AA14984@clio.rice.edu>
Subject: Re: mntent problem summary on Win2K/XP
To: eliz AT is DOT elta DOT co DOT il
Date: Mon, 1 Oct 2001 08:32:17 -0500 (CDT)
Cc: wojciech DOT galazka AT polkomtel DOT com DOT pl, djgpp-workers AT delorie DOT com
In-Reply-To: <9003-Mon01Oct2001125723+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Oct 01, 2001 12:57:23 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

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

The set of lfn=n fixed the problem, so we don't have to make a hard
decision here.  Next question - is it worth the effort to skip the
putenv calls and replace the current findfirst loop with direct call
to the DTA call followed by potentially looping the 4e interrupt?

As slow as getmntent currently is searching for missing floppies and
network drives, I didn't think it would make much difference.