'mv foo ..' when . is foo

Guy Harris guy at sun.uucp
Sat Aug 24 15:44:50 AEST 1985


> I just did the following by accident (edited to preserve essential
> point - gh):
> 
> 	mkdir foo		# Make a temporary directory
> 	cd foo
>	>foo
> 	mv foo ..
> 	 .
> 	 .	# Now, what's the name of my current directory?
> 	 .
> 	pwd	# This produces "pwd: read error in .."
> 
> Is this a feature?

Hell, no.  That's a bug.  "mv" should carefully check that it's not
unlinking a non-empty directory; since unlinking the target is the first
operation performed in this move, "foo/foo" should exist and the unlink of
"foo" should be illegal.

4.2BSD, bless its soul, introduced a "rename" system call which

	1) performs the unlink target/link target to source/unlink source
	   operation as one pretty-much-atomic-operation,

	2) is only a rename, and as such doesn't require superuser
	   privileges to rename a directory (since making extra
	   links to a directory is uncool, and unlinking a non-empty
	   directory is *very* uncool, UNIX restricts linking to
	   and unlinking directories to the superuser)

and

	3) checks for all the nasty cases of moving a directory to
	   a subdirectory of itself, etc., so it is safe.

It also doesn't permit you to rename a non-directory if the target to be
removed is a directory, or vice versa; I presume this is a case of
foolproofing.  The above sequence results in

	mv: rename: Not a directory

(or an equivalent but less informative error message if "mv" doesn't use
"perror" or "sys_errlist") on a 4.2BSD system for that very reason.  (And
if it did permit those kinds of mixed renames, it'd say

	mv: rename: Directory not empty

instead.)

Making it a standard library operation also makes it easier to move code to
systems which don't support "link" and "unlink" the way UNIX does, but do
support a "rename" operation.  (The same is true of "mkdir" and "rmdir" -
which are non-privileged system calls in 4.2BSD, so you don't have to "exec"
the "mkdir" or "rmdir" command, which won't work if you're a set-UID program
- and of the directory reading routines.)

	Guy Harris



More information about the Net.bugs mailing list