rename strangeness, a possible bug

[Chris Torek]

In article <1078 at virtech.UUCP> cpcahil at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris