From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10110011339.AA14994@clio.rice.edu>
Subject: Re: fixpath patch (rev 3)
To: djgpp-workers AT delorie DOT com
Date: Mon, 1 Oct 2001 08:39:37 -0500 (CDT)
In-Reply-To: <1001939971.21288.22.camel@bender.falconsoft.be> from "Tim Van Holder" at Oct 01, 2001 02:39:30 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

> > > Note that I would prefer /dev/[bogus] or something similar, to avoid
> > > any and all issues with colons (either as drive or path separator).
> > 
> > What issues are those?
> > 
> > If you are afraid of commands that fail, that's okay: we _want_ them
> > to fail when this happens.  We just want them to fail in the least
> > dangerous way.
> 
> I was thinking along the lines of a Unixy program building a Unixy path
> list using /dev/:bogus:, which would lead to '/dev/' and 'bogus' being
> used.

OK, this is in fixpath, which insists on a return form of d:/dir/dir ...
and the users of fixpath break badly if the first 2 return letters are
not d: ... (expecting the 3rd to always be / and not checking for it
was only in one place and that was an easy fix).

So, it would have to be a return of something like d:/:bogus:/ - and so
far we've only seen getcwd fail for long paths with lfn=n ...

Right now I'm using a relative path if getcwd fails ("d:.") which seems
to have fixed a few things without breaking anything I've noticed.  Since
this is only in long dirs with lfn=n, hard to see (it would use d:\
previously).