delorie.com/archives/browse.cgi | search |
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 |
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 |
> 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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |