Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3BADCF7E.B1BE84@phekda.freeserve.co.uk>
Date:	Sun, 23 Sep 2001 13:03:10 +0100
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: gcc-3.01 seems unstable
References:	<250B3114DA16D511B82C00E0094005F8023FC197 AT MSGWAW11>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Wojciech Galazka wrote:
> I'm writting once again to let you know there is a problem with absolute
> path names whose sizes is very large ( > 67 chars, perhaps)
> under W2k I only started looking at this and it seems that if a pathname
> is too long then a root directory (\) is used instead
> so rm -rf \very_long_path\*.*
> results in
> rm -rf \*.*

This reminds me of a problem that I hit when I was porting Fileutils 4.0.
IIRC the problem arose in the Fileutils testsuite when I was running with
LFN=n under Windows 98 'SE.

The mail I sent to djgpp-workers was entitled "Re: Bash problem with SFN".
I sent it on Sun, 04 Mar 2001 16:38:44 +0000. Mark E replied on Sun, 4 Mar
2001 16:02:33 -0500. Eli replied on Mon, 5 Mar 2001 09:35:55 +0200 (IST).

The problem was that directory names are limited to 64 chars, when calling
chdir() with LFN=n. It appeared that the current working was lost and
programs (e.g. 'ls') started to use the root directory as their current
directory.

Eli said this:

"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 ;-)"

I took that advice and never tried LFN=n tests under Windows again. (There
is also a note in gnu/filutil4.0/djgpp/readme.dos that warns against
running tests under Windows with LFN=n.)

Now to the problem: I've tried to keep up with the Win2k discussions. From
what I remember some file handling is done with SFNs, because Win2k's LFN
handling is a bit broken. So perhaps the changes expose the same problems
I experienced when running the Fileutils tests with LFN=n on Windows '98
SE?

Unfortunately I don't have access to Win2k. I can, however, try to help
anyone who wants to debug using the Fileutils test I used.

> This has just happened to me and I lost 700 MB of some programs :)
> when I tried to continue compiling libstdc++-v3.

I am sorry to hear that. I hope you didn't lose anything
important/unrecoverable.

Bye, Rich =(

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/

- Raw text -