Message-ID: <250B3114DA16D511B82C00E0094005F8023FC19B@MSGWAW11>
From: Wojciech Galazka <wojciech DOT galazka AT polkomtel DOT com DOT pl>
To: "'djgpp-workers AT delorie DOT com'" <djgpp-workers AT delorie DOT com>
Cc: eliz AT is DOT elta DOT co DOT il
Subject: RE: Win 2000 rm -rf disaster info
Date: Mon, 24 Sep 2001 23:53:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Reply-To: djgpp-workers AT delorie DOT com



> -----Original Message-----
> From: sandmann AT clio DOT rice DOT edu [mailto:sandmann AT clio DOT rice DOT edu]

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

I can reproduce these problems as well
results follow
LFN =y
binaries (rm.exe ) from clio from Sept-04-2001
	
system			with LFN driver	without LFN driver
NT 4.0 Wks SP 6		#1		#1
W2k Adv Srv SP2		#2		#3

#1 will not change to .libs/libstdc++.lax directory, returns with ENOENT,
remains in the original directory from within rm -ri was run
#2 returns with ENOENT, switches to the root directory
#3 will attempt to remove root directory

These results suggest that it is set current directory call that is broken
under w2k ntvdm  (int 21h, ah=3bh)
If there are no issues with Win9x (when lfn=y) then perhaps this would be
easy to fix this if it was possible to distinguish W2k from NT 4.0
But since it's not possible then we should check if the absolute path, the
program changed to, is the same as the absolute path
the program was supposed to enter.