Mail Archives: djgpp-workers/2001/09/28/05:41:15
> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Fri, 28 Sep 2001 00:02:01 -0500 (CDT)
>
> 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?
> Now, lets take the Win9x bug next. If getcwd fails completely, what do
> we do in fixpath? There is no failure code from fixpath. We currently
> don't support returns of relative paths (but this would be easy to fix,
> I don't know if it would break anything). We could create some bogus
> name so everything would fail using the fixpath'ed name (right now we
> use root). We could perror a message and exit. 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.
> 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.
- Raw text -