From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10109231606.AA13897@clio.rice.edu>
Subject: rm -rf disaster bug [was Re: gcc-3.01 seems unstable]
To: djgpp-workers AT delorie DOT com
Date: Sun, 23 Sep 2001 11:06:14 -0500 (CDT)
In-Reply-To: <3BADCF7E.B1BE84@phekda.freeserve.co.uk> from "Richard Dawe" at Sep 23, 2001 01:03:10 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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
Precedence: bulk

> 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 \*.*

For someone with inadequate backups, this strikes unbelieveable fear ...

> 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 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).

If this is the case the code should have an assert in it and bail if
there are more than 64 chars.  We shouldn't leave the possibility of
going to root.  Silent failure can be deadly.  I don't know if this is
a libc problem (silent failure) or application failure (ignorning return
code).

> 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?

We are only doing this for open() related handles.  No changes have been 
made to findfirst or stat.  There may be horrible lurking bugs (which might
have caused this) but nothing we have done with SFNs yet.  It is a good
point - what happens with our SFN opens if the resulting SFN name is
too deep or too long?  For that matter, what does NT's lfn stuff do?

> 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.

I'm interested (petrified-with-fear is probably a better term). I'll try 
to look at the old messages in the archive, but any additional info is 
appreciated.