Mail Archives: djgpp-workers/2001/09/28/01:07:38
Test results:
Windows 2000: Can not launch DOS program if current directory SFN > 64 char
LFN=y change dir (relative) to long name OK, dir changes,
get dir shows root (BUG), truename OK
LFN=n change dir (relative) to long fails ENOENT, dir changes,
get dir truncated to 64, truename bogus (same as dir), not root
Windows 95OSR2: Can launch DOS program if current directory SFN > 64 chars,
but any get directory call fails with ENODEV (BUG)
LFN=y (no known issues)
LFN=n change dir (relative) to long OK (BUG), dir changes,
get dir fails (ENODEV), truename fails (ENOENT), treat as root
Windows XPRC1: (same as Windows 2000)
Windows NT 4: Can not launch DOS program if current dir SFN > 64 char
LFN=n change dir (relative) to long fails ENOENT, dir does not change.
DOS '95: Can not change directory if SFN > 64 char (dir from W95)
LFN=n change dir (relative) to long fails ENOENT, dir does not change.
Other systems unknown, untested, but let me extrapolate...
Under Windows 2000/XP, 2 bugs:
if LFN=y, directory is long (short name > 64), get dir shows root (0x7147 bug)
if LFN=n, change dir to long returns failure but changes (and bogus).
This doesn't hurt anything (you get failure code, if you ignored it
you will fail due to bad values).
Under Win95:
if LFN=n, can launch from bad directory, can change dir to long directory,
but get dir fails, truename fails, must use relative paths (but works OK)
Let's take the W2K bug first. We can check for lfn=y, version=532, and
in this case validate only root directory returns from getcwd with the
truename call. A very narrow test. Since NT/W2K never returns UNC in
truename, simple code. This could also be added to the getcwd call.
Could treat UNC return as root just in case.
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. Using a
bogus path allows application to recover more gracefully (maybe) and is
similar to the case of an invalid drive. Just trying to fix chdir()
isn't enough of a fix for Win9x since we can start the program in an
invalid directory (not a problem on NT/2K/XP/DOS). I don't think the
perror/exit is an option since an invalid drive shouldn't kill the
program. So I think relative paths or a made-up invalid directory
name (3+ periods?) would be better. But I worry about paths with ..
in them, which could "clear" our bogus directory and put us back to
a root situation. If no one has a good suggestion I'll return a
relative path and let other things break if they break.
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.
Test program (src+bin) is in ftp://clio.rice.edu/djgpp/fixpathtest.zip
I will probably leave the new test code included in the test image in an
updated fixpath.c when committed.
- Raw text -