Date: Mon, 12 Feb 2001 21:44:11 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Laurynas Biveinis" <lauras AT softhome DOT net>
Message-Id: <9743-Mon12Feb2001214411+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp-workers AT delorie DOT com
In-reply-to: <20010212140538.614.qmail@lauras.lt>
Subject: Re: Bash problem with SFN
References: <3A86B90D DOT 15400 DOT 11A13E4 AT localhost> <Pine DOT SUN DOT 3 DOT 91 DOT 1010212092757 DOT 12969F-100000 AT is> <3A8792AA DOT 26825 DOT 7F4B2 AT localhost> <20010212140538 DOT 614 DOT qmail AT lauras DOT lt>
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

> 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.