From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10109281936.AA16509@clio.rice.edu>
Subject:	Re: fixpath patch (more clarification)
To:	eliz AT is DOT elta DOT co DOT il
Date:	Fri, 28 Sep 2001 14:36:44 -0500 (CDT)
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<557-Fri28Sep2001204304+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 28, 2001 08:43:04 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

> Well, on W2K, you never call 216000h, only 217160h, right?  

Correct.  And we only call 7160 for NT/W2K/XP.
(And it needs tweeked arguments to handle subst drives properly, bug
in current test code confirmed).  

I don't think this will ever trigger on NT+lfn since 
previous tests show the CD will fail.  However, subst does look like
a very effective workaround to go lower in the tree on NT :-)

The code should never ever call Ah=60 (this is some dead code in the 
test program to be removed).

> Since you said AH=60h, I thought you were talking about Windows 9X.

Sorry for the confusion.  If the getcwd call on Win9x (or other platforms) 
fails it will return a relative path (without ever calling truename).
I have not found a single case where getcwd failed and any truename
was successful, so it would be useless (and dangerous) to code this.

If lfn=y and ver=0x532 and getcwd is successful and shows a root dir,
we call 7160 cx=8002 to validate it is really a root dir.  If 7160 
fails, (never seen) or doesn't return the drive we expect (not seen 
except subst problem) and the ":" we would either return the relative 
path d:. or d:\ (since I can't make this happen yet, I lean towards 
d:.).  I hate coding error cases I don't know if will ever happen.

Sorry for the painful discussion, but it really does 
result in much better code when we discuss all the changes and why ...

- Raw text -