Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: rename strangeness, a possible bug
Message-ID: <19280@mimsy.UUCP>
Date: 26 Aug 89 19:21:38 GMT
References: <24612@santra.UUCP> <8352@boring.cwi.nl> <647@cbnewsi.ATT.COM> <1078@virtech.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 30

In article <1078@virtech.UUCP> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>Another problem is (due to the fact that the move will not be and atomic 
>operation) what happens if the command is interrupted (with a kill -9, so
>it doesn't have a chance to clean up)?  Do we now have a corrupted file
>system?

This is why rename() is in the 4BSD kernel (for `BSD' >= `.2' :-) ).

As for the original question, the answer is here, in the beginning of
the rename() syscall (ufs_syscalls.c).

	dp = ndp->ni_pdir;
	/*
	 * If ".." must be changed (ie the directory gets a new
	 * parent) then the source directory must not be in the
	 * directory heirarchy above the target, as this would
	 * orphan everything below the source directory. Also
	 * the user must have write permission in the source so
	 * as to be able to change "..". We must repeat the call 
	 * to namei, as the parent directory is unlocked by the
	 * call to checkpath().
	 */
	if (oldparent != dp->i_number)
		newparent = dp->i_number;
	if (doingdirectory && newparent) {
		if (access(ip, IWRITE))
			goto bad;
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris