Mail Archives: djgpp-workers/2001/09/28/11:07:23
> > 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 :-)
- Raw text -