Mail Archives: djgpp-workers/2001/02/12/14:45:22
> From: "Laurynas Biveinis" <lauras AT softhome DOT net>
> Date: Mon, 12 Feb 2001 16:05:38 +0200
>
> But as you showed in your previous mail, this problem exists at a library
> level. Maybe chdir() should be patched instead?
It's not a library problem, it's a Windows problem. On plain DOS,
Mark's test program works as you'd expect (i.e. it succeeds to create
the file).
In fact, we already heard about similar problems in the past, just not
in conjunction with Bash. I remember several reports from people who
used DOS programs (which obviously use legacy DOS calls, not the LFN
API), and after changing to some directory, they found that some
file-oriented commands failed or worked strangely.
Note that when the program finishes, COMMAND.COM shows "longlonglong"
in its prompt as the current directory, not the correct "longlong".
I'm guessing that Windows gets confused when it sees a long directory
name in a DOS (non-LFN) chdir call. It might, for example, fail to
normalize "longlonglong" to the 8+3 form before sticking it into its
CDS structure, where other system calls get the current directory.
Working around this in the library would involve an additional Int 2F
call (to find out whether we run on Windows), and some non-trivial
code to normalize the long file name to its proper 8+3 form (or a call
to Int 21h/AH=60h). I'm open to opinions, but frankly I'm not sure if
this bloat is justified: running with LFN=n on Windows is a bad idea
anyway (because only DJGPP programs honor LFN=n). People who want to
test their programs without LFN should really boot into DOS.
If we decide not to implement a work-around in the library, it's
probably okay for Bash to do that, if people think this is a grave
problem.
- Raw text -