mbr@aoa.UUCP (Mark Rosenthal) (08/23/85)
Although our site has been receiving articles for the past few months,
articles posted to the net have not been getting distributed until recently.
The following is a reposting of an article I sent out quite some time ago.
I believe it never made it to the net at large. Apologies if you have seen
this before.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I just did the following by accident:
mkdir foo # Make a temporary directory
cd foo
.
.
.
<lots of editing>
.
. # Time passes. I forget what directory I'm in.
. # I need a temporary file name. How about 'foo'.
.
<create file foo>
.
. # More time passes. Lets save foo where it'll
. # be safe when I delete my current directory.
.
mv foo ..
.
. # Now, what's the name of my current directory?
.
pwd # This produces "pwd: read error in .."
Is this a feature?
BTW, I was logged in as root at the time. It turns out that it doesn't
work this way if you're not. We are running a port of Sys V on the
Masscomp MC500.
--
Mark of the Valley of Roses
...!{decvax,linus,ima,ihnp4}!bbncca!aoa!mbrguy@sun.uucp (Guy Harris) (08/24/85)
> 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
rcj@burl.UUCP (Curtis Jackson) (08/25/85)
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
robin@medstar.UUCP (Robin Cutshaw) (08/26/85)
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!robintim@cithep.UucP (Tim Smith ) (08/28/85)
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!
--
unlk a6
rts
Tim Smith
ihnp4!{wlbr!callan,cithep}!timsean@ukma.UUCP (Sean Casey) (09/02/85)
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