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 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/