From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10109240223.AA03185@clio.rice.edu>
Subject: Re: rm -rf disaster bug [was Re: gcc-3.01 seems unstable]
To: eliz AT is DOT elta DOT co DOT il
Date: Sun, 23 Sep 2001 21:23:16 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <1659-Sun23Sep2001211042+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 23, 2001 09:10:43 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

The problem only happens when the short name length equivalent (w/o drive) 
of the directory exceeds 64 characters (even when using lfn functions).

Wrote a simple test program to chdir to args on command line, printing
return codes and results from getcwd at each step.  Two args:
.libs/libstdc++.lax ..

Using long names:
 can cd to the directory (no failure).  If the short name equivalent
 of the directory is > 64 characters, getcwd returns d:\
 What is more interesting is from that point if I change directory a 
 second time to .. (in the same image) - it changes to the correct 
 directory and prints the correct name.  So the problem seems to be
 completely with getcwd in the test (I'm guessing that findfirst 
 internally hits the same buggy problem inside Win2K?)

Using short names (lfn=n):
 can cd to the directory (but returns failure ENOENT) - but that directory
 is actually current.  getcwd returns the name truncated to 64-characters
 (a partial part of the name on the last name displayed).  Second change
 dir to .. works just fine as above.

ls can see all the files in directories - so this seems to be a current
working directory limitation (if you don't change directory not a problem).

Now, if I use the LFN TSR - I get a chdir failed message, I get a getcwd
failed message (but my current directory did actually change!) and the
second change to .. works.  So running with the TSR actually causes rm -ir
to see an error and fail. (It does leave you in the nested directory
however, with the short name in my prompt being the truncated value...).
So to protect your files, run with the LFN TSR (which prevents you from
going too deep).

I'll have to look and see if we can add some protection for this.