Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!munnari!basser!mbd
From: mbd@basser.oz (David)
Newsgroups: comp.os.minix
Subject: Re: Request for help with rmdir bug
Message-ID: <939@basser.oz>
Date: Fri, 5-Jun-87 04:34:09 EDT
Article-I.D.: basser.939
Posted: Fri Jun  5 04:34:09 1987
Date-Received: Tue, 9-Jun-87 05:08:13 EDT
References: <1195@botter.cs.vu.nl>
Organization: Dept. of Comp. Science, Uni of Sydney, Australia
Lines: 26
Summary: possible solution is to cd to the 'dirname(1)' part of the given directory.

In article <1195@botter.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes:
> 
> It has been previously reported that there is a bug in rmdir.  If you type
> 
> mkdir foo
> rmdir foo/../foo
> 
> rmdir fails.  I checked the code of rmdir.  What happens is that rmdir
> first unlinks . and .. from foo, then it tries to access foo/../foo to
> unlink the directory, but that path is no longer valid because .. is now
> gone.  I tried the same test on our VAX with 4.1 BSD and it failed
> there too.  
It seems to work ok on our VAX running hacked up 32V, but I don't have
any way to check that the directory is not orphaned.
> 
I haven't tried this but:
	first cd to the directory specified by all but the last bit
	of the named directory ( i.e. if given foo/../foo then foo/.. )
	( This corresponds to what the 'dirname' command does ... )
	and then apply the existing algorithm to the last part.
Possible problem:
	Leaves you with a different current directory ( only a problem
	if you have multiple directories to remove. ).

The possible solution was suggested by Ralph Seberry.
Michael Barr-David (mbd@basser.oz.au)