Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3AA26F94.37659828@phekda.freeserve.co.uk>
Date:	Sun, 04 Mar 2001 16:38:44 +0000
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.51 [en] (X11; I; Linux 2.2.17 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Bash problem with SFN
References:	<20010212170159 DOT 236 DOT qmail AT lauras DOT lt> <3A888358 DOT 22611 DOT 233A32 AT localhost>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

"Mark E." wrote:
> You may be right. I found several bugs that affected the builtin cd
> command and the change exposed one of them. In getting cd working right,
> I decided to remove the 'longlonglong -> longlong' problem hashed over
> yesterday since AFAIK this is a rather obscure problem that is solved
> with LFN=Y.
> 
> I've uploaded this new version to
> http://members.xoom.com/snowball3/djgpp/ .
[snip]

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:

As you may imagine, this bug could be a bit unpleasant if the rm test
managed to recursively delete everything in
/temp/sfn/filutil4.0/tests/rm/t-rm.125/k/k/k/k/k/k/k/k/k/k/k/k/k.
Fortunately it fails (phew).

Bye, Rich =]

-- 
Richard Dawe <richdawe AT bigfoot DOT com> http://www.bigfoot.com/~richdawe/ 

"The soul is the mirror of an indestructible universe."
--- Gottfried W. Leibniz

- Raw text -