Date: Mon, 24 Sep 2001 12:14:39 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Charles Sandmann 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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.