From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10109281501.AA16530@clio.rice.edu>
Subject: Re: fixpath patch (testing info, suggestions)
To: eliz AT is DOT elta DOT co DOT il
Date: Fri, 28 Sep 2001 10:01:21 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <1659-Fri28Sep2001113915+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 28, 2001 11:39:16 AM
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

> > Windows 95OSR2: Can launch DOS program if current directory SFN > 64 chars,
> >         but any get directory call fails with ENODEV (BUG)
> 
> Is this for LFN=n, or even with LFN calls?  And when you say BUG, do
> you mean there's a bug in what our getcwd does, or a bug in Windows?

This is for LFN=n.  I consider this a bug in Windows 9x that you can 
launch a DOS-based program from a directory that the OS will tell you
does not exist.  Allowing it to launch assumes it will use the long
name API everywhere.  The NT/Win2K/XP method of disallowing this makes
more sense to me.

> > If getcwd fails completely [on Win9x], what do we do in fixpath?  We
> > don't support returns of relative paths (but this would be easy to fix,
> > I don't know if it would break anything).  [...] Relative paths might
> > allow some functionality to work, but might cause new bugs.
> 
> I think, on balance, returning "d:./" is the best alternative.  It
> shouldn't cause too much harm, and in many cases will silently DTRT.
> Those cases which fail are no worse than if we return a failure or
> some bogus directory.

It does seem to make the most sense.  I'll test it with some fileutils
to see if lfn=n in deep directories behaves.  The options were "d:"
"d:." or "d:./." (fixpath does not return trailing / except on root).

> > For now, I'll focus on the Win2K path since it's very clear to me what
> > should be done there to fix that bug.
> 
> Indeed.  The Windows 9X issue is an old problem which we live with for
> a long time.  I guess setting LFN=n on Windows is not something people
> do too often.

Since it's 5 lines away in the same module I'm patching, I thought I would
fix it at the same time :-)