Date:	Mon, 5 Mar 2001 09:35:55 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Bash problem with SFN
In-Reply-To:	<3AA26F94.37659828@phekda.freeserve.co.uk>
Message-ID:	<Pine.SUN.3.91.1010305093527.23825K-100000@is>
MIME-Version:	1.0
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

On Sun, 4 Mar 2001, Richard Dawe wrote:

> OK, I've hit another problem in bash with LFN=n under Windows '98 SE. The
> Fileutils test suite creates a lot of nested directories to test 'rm'.
> 
> /temp/sfn/filutil4.0/tests/rm/t-rm.125/k/k/k/k/k/k/k/k/k/k/k/k/k
> 
> This path is 64 characters long, incidentally (the maximum for an SFN?).
> If I 'cd' to this directory and then do 'ls', I see the root directory.
> 'LFN=n ls -al' shows the root directory, while 'LFN=y ls -al' shows the
> contents of that directory. If I try to invoke Emacs from this directory
> using 'LFN=n /djgpp/gnu/emacs/bin/emacs.exe', I get:
> 
> emacs: `getwd' failed:

It's all expected: legacy DOS calls are limited to 64 characters in
the directory part of a file name, and to 8 levels of subdirectories
(which you exceeded).

I'd like to reiterate what I said on numerous occasions here: do NOT
use LFN=n on Windows as a way to test how programs work without long
file names.  It might work for simple tests, but will fail for
anything as serious as running a complicated test suite.

If you want to test without LFN, boot into DOS, or go to the DOS Mode,
and test there.  You will be a happier person, believe me ;-)

- Raw text -