delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/09/30/12:17:38

From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10109301612.AA17719@clio.rice.edu>
Subject: Re: mntent problem summary on Win2K/XP
To: eliz AT is DOT elta DOT co DOT il
Date: Sun, 30 Sep 2001 11:12:46 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <9003-Sun30Sep2001093244+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 30, 2001 09:32:44 AM
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

> > findfirst does not find volume labels.  It returns all files (but not
> > volume labels...).  Checking the returned attributes and ignoring it
> > if the label bit is not set is probably the best fix here (then we
> > show "Drive X:" syntax.  This fix is probably best done in findfirst.
> 
> I don't think you can do that in findfirst: returning a failure on the
> first file it returns is not right, since W2K returns all files; and
> looping until you exhaust all files, looking for a real label, is also
> something we don't want, I think.

I hadn't looked at it yet.  I'll do the local test (one additional test
in the if statement).

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

There is currently a test in the code to make sure hidden and system bits
are not set in the returned entry.  I added a check to see if the volume
bit was set.  This fixed the problem and did not hurt other systems I
tested it on.  No need to make it specific for Win2K (which would hurt
NT + LFN which seems to work).

> > My CDROM drive is mounted and ready but it does not show up at all
> > (not debugged yet).
> 
> The CD-specific calls in cdrom_drive_ready probably don't work as
> expected...

I added some printf statements and it seemed to return the expected 
values.  If I get more time I'll look at it further.

I did find one thing in the current code, a comparison to 0x332 as the
dos version, with a comment saying NT.  Should this be 0x532 ?

> > Drives > 26 (which is also cds_drives) succeed in truename for some
> > unknown reason.  I just disabled returns for drives > cds_drives if
> > version = 0x532 and I get a more normal display.  
> 
> A good move, I think.

It was a simple fix.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019