delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/03/05/02:37:54

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019