🚀 go-pugleaf

> 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

I am running Sys V r2, and here is what happens when I do what you talked
about as root:

# mkdir foo
# cd foo
# touch foo
# mv foo ..
# pwd
/emsp/rcj/test/foo
# cd ..
# ls -ld foo
-rw-r--r--   1 root     sys            0 Aug 25 10:36 foo
# cd foo
mycd: foo: bad directory
#

So the behavior is apparently different from both your Sys V port and
from 4.?BSD.
-- 

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
			...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj

I have noticed this same problem with Xenix on the AT.  The only way to
get the directory contents back is to run fsck on the filesystem.

-robin
-- 
----
Robin Cutshaw
uucp:   ...!{akgua,gatech}!medstar!robin

In article <118@cithep.UucP> tim@cithep.UucP (Tim Smith ) writes:
>At cithep, this is what happens:
>
>$ mkdir foo
>$ cd foo
>$ touch foo
>$ mv foo ..
>mv: ../foo is a directory
>$
>I don't quite know what version of UNIX cithep is any more ( At one
>time this machine had parts or 32V, TS 1.?, Sys III, and 4.1bsd
>pageing code ( cleaned up, of course )).  God only knows where mv
>came from!

Uhhh, this is correct behavior for mv.  What you are trying to do is
clobber a directory by moving a file, a definite no-no.

Sean


-- 

-  Sean Casey                           UUCP:   sean@ukma.UUCP   or
-  Department of Mathematics                    {cbosgd,anlams,hasmed}!ukma!sean
-  University of Kentucky               ARPA:   ukma!sean@ANL-MCS.ARPA