Date:	Mon, 24 Sep 2001 12:14:39 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Win 2000 rm -rf disaster info
In-Reply-To:	<10109240049.AA03150@clio.rice.edu>
Message-ID:	<Pine.SUN.3.91.1010924121204.25254K-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, 23 Sep 2001, Charles Sandmann wrote:

> > From partial logs that I had on the disk it seems that in the direcory
> > \djgpp.2\gnu\gcc-3.02\build.djg\i586-pc-msdosdjgpp\libstdc++-v3\src
> > an attempt was made to delete the subdirectory 
> > .libs\libstdc++.lax
> > that resulted in deleteion of  \ instead
> 
> I created a directory with the name above; then subdirectory as above.
> 
> I can reproduce this horrible behavior.  Using Eli's suggestion of rm -ir
> it asks if I want to decend into that directory, I say yes, and then it
> proceeds to list directories/files in the root.

I can see the same on Windows 98 SE, but only if I set LFN=n (and
modify the file name to use 8+3 aliases instead of names like .libs
and libstdc++).  With LFN support active, there are no problems,
everything works as I'd expect.

Also, when I set LFN=n and try "rm -ir", I get the following message
for each directory I tell `rm' to descend into:

  rm: directory djgpp.2/gnu/gcc-3.03/build.djg/i586-pc-msdosdjgpp/libstdc_/src/libs/libstdc_.lax/recycled' is write protected; descend into it anyway?

So it thinks those fake directories are ``write-protected''...

> If I ctrl-C out it leaves
> me in the lower directory - but any attempt to run dos/djgpp images that
> low in the directory tree generates an error "The system cannot execute
> the specified program."

It's different here: I, too, am dumped in the lower directory, but
running DJGPP programs _does_ work, and those programs behave as if
they were in the root.  For example, `ls' prints the names of the
files in the root directory.  Unsetting LFN gets me back the normal
behavior, i.e. `ls' prints nothing (as the directory is empty).

If I invoke `pwd' with LFN=n in the low directory, I get this:

 pwd.exe: cannot get current directory: No such device (ENODEV)

With LFN unset, `pwd' works as expected.

Based on these observations, I think the problem is with the current
working directory in SFN functions: they cannot cope with directories
which are more than 8 levels deep and/or too long.

Since the problem happens in W2K even when LFN support should be active, 
I'm speculating that they didn't rework some of the NT emulation to 
accomodate long file names; sounds like the equivalent of the DOS CDS 
(Current Directory Structure) was left in its previous state.

I will try this on plain DOS in the evening, but I think DOS will not
let me create such a deep directory at all.

- Raw text -