From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10109291417.AA12467@clio.rice.edu>
Subject:	Re: fixpath patch (rev 3)
To:	eliz AT is DOT elta DOT co DOT il
Date:	Sat, 29 Sep 2001 09:17:44 -0500 (CDT)
Cc:	wojciech DOT galazka AT polkomtel DOT com DOT pl, djgpp-workers AT delorie DOT com
In-Reply-To:	<7704-Sat29Sep2001120527+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 29, 2001 12:05:28 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

> Looks fine, but I thought we agreed that the carry flag should be set
> before calling 4700h/7147h?

Humm, I had that in one version.  Too many computers, too little time...
No problem, I can add it back.  (However, checking the RBIL info, it seems
this is only an issue if lfn should not be set, which we check for elsewhere).
One line for safety doesn't hurt...

> > It will only behave differently than the well tested fixpath if getcwd
> > fails (which we didn't handle before - it now becomes relative path) or
> > if Win2000 type OS (lfn and 0x532) and a seemingly root directory.
> 
> There's a subtle issue with _fixpath returning "d:." in these cases:
> if a program chdirs between opendir and readdir, the wrong directory
> will be read.  If we cannot fix that, we should at least document it.

I could not see any way to fix it.  The only way I can create it in testing
is deep paths on W9x with lfn=n (it seems like dead code for Win2K).
I agree it should be documented.  Avoiding lfn=n with deep paths will
probably still be wise.  

I want to play with the fileutils on W9x lfn=n long paths and see if 
I see any unexpected behavior before unleashing this.  If so, we should
probably set a bogus directory name instead (so everything always fails).
Maybe "too deep" or something for error message hints ...

- Raw text -