"oread::barbanis"@CS-UMASS.arpa (11/29/87)
Subject: Bug in Ultrix 2.0 ?
If you are a superuser and do unlink("foo"), it always unlinks,
even if foo is a directory, and even if this directory is not
empty. I wondered what happened to the directory contents,
so I did some experimenting:
$ mkdir foo
$ cat > foo/bar
ksadkjashdkjahdkaskjda
^D
$ ls -l foo/bar
(one link to foo/bar)
$ ln foo/bar baz
$ ls -l foo/bar baz
(2 links to foo/bar and baz)
$ run program that does unlink("foo") -- runs ok.
$ ls -l foo baz
(foo does not exist, but baz is reported as having *two* links to
it)
$ cat baz
ksadkjashdkjahdkaskjda
After this amazing feat of Ultrix prestidigitation, I tried the
same on Sun (as root on the file server). Of course it exited
with [EPERM], which is as it should be.
And they say DEC software is dull...
George Barbanis
Computer & Information Science
Univ. of Mass. -- Amherst
barbanis@cs.umass.edugwyn@brl-smoke.ARPA (Doug Gwyn ) (11/29/87)
In article <10570@brl-adm.ARPA> "oread::barbanis"@CS-UMASS.arpa writes: >$ ls -l foo baz >(foo does not exist, but baz is reported as having *two* links to it) That's not a bug, that's exactly what I would expect. Just because you were silly enough to lose the link to the directory inode does not mean that you have affected the link count of inodes that used to be located via that directory. Unlinking a directory is restricted to the super-user in order to maintain the integrity of the hierarchical file system structure. It is not expected that privileged software would mess around with this structure! Run "fsck" to fix your messed-up filesystem before it's too late...
chris@mimsy.UUCP (Chris Torek) (11/29/87)
In article <10570@brl-adm.ARPA> "oread::barbanis"@CS-UMASS.arpa writes: >If you are a superuser and do unlink("foo"), it always unlinks, >even if foo is a directory, and even if this directory is not >empty. This is not a bug. This is a feature. How else are you going to remove an extra link to a directory when a directory somehow acquires one (disk glitch, kernel bug, or whatever)? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ron@topaz.rutgers.edu.UUCP (11/29/87)
The whole purpose of "unlink" as opposed to "rm" is to get around all these nice consistency checks like "file is a directory" that rm does for you. Linking and unlinking directories makes a mess of your file system topology, and hence it is reserved for the superuser. Rmdir verifies that the directory is empty before removing it, and it also removes the links for . and .. (well at least ..) before blowing things away. Unlinking a directory causes small parts of your filesystem (still allocated) to drift away so that no one can access them. -Ron
"oread::barbanis"@CS-UMASS.arpa (12/02/87)
>>If you are a superuser and do unlink("foo"), it always unlinks, >>even if foo is a directory, and even if this directory is not >>empty. > >This is not a bug. This is a feature. How else are you going to >remove an extra link to a directory when a directory somehow acquires >one (disk glitch, kernel bug, or whatever OK, so I was wrong; unlink(2) is supposed to unlink a (full) directory *if* you are the superuser, and that's the way it works on Ultrix. (It's in the manual, too... :-) ) However, it does not work on Sun Unix 4.2, not even if you are the superuser (no, it is not NFS; I tried it on the server). Unlink returns [EPERM] if you try it on a directory. So what's wrong? George Barbanis UMass -- Amherst
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/02/87)
In article <10617@brl-adm.ARPA> "oread::barbanis"@CS-UMASS.arpa writes: >However, it does not work on Sun Unix 4.2, not even if you are the >superuser (no, it is not NFS; I tried it on the server). Unlink >returns [EPERM] if you try it on a directory. So what's wrong? Systems that have a decent rmdir() system call do not need to allow unlink() to succeed on a directory. Apparently Sun is in this category.
chris@mimsy.UUCP (Chris Torek) (12/02/87)
In article <10617@brl-adm.ARPA> "oread::barbanis"@CS-UMASS.arpa writes: >... unlink(2) is supposed to unlink a (full) directory *if* you are >the superuser, and that's the way it works on Ultrix. (It's in the >manual, too... :-) ) However, it does not work on Sun Unix 4.2... Clearly Sun decided it was a bad feature and deleted it. Then again, Sun does not have 4.1BSD compatibility code in their kernels.... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ron@topaz.rutgers.edu.UUCP (12/02/87)
Unlike older UNICES and SYSTEM V, the BSD directories are managed by atomic system calls that any user can execute. Other UNIX systems require you to run setuid root programs that very carefully use mknod, link, and unlink to set up the directories and their . and .. entries. -Ron
decot@hpisod2.HP.COM (Dave Decot) (12/03/87)
> In article <10617@brl-adm.ARPA> "oread::barbanis"@CS-UMASS.arpa writes: > >However, it does not work on Sun Unix 4.2, not even if you are the > >superuser (no, it is not NFS; I tried it on the server). Unlink > >returns [EPERM] if you try it on a directory. So what's wrong? > > Systems that have a decent rmdir() system call do not need to allow > unlink() to succeed on a directory. Apparently Sun is in this category. And a decent rename() call. You would still need unlink() to move directories from here to there if you didn't have rename(). Dave Decot hpda!decot
zemon@felix.UUCP (Art Zemon) (12/05/87)
In article <10570@brl-adm.ARPA> "oread::barbanis"@CS-UMASS.arpa writes: >Subject: Bug in Ultrix 2.0 ? >If you are a superuser and do unlink("foo"), it always unlinks, >even if foo is a directory, and even if this directory is not >empty. This isn't a bug in Ultrix, the same "problem" also existed in 4.2 BSD (the only other system on which I, ahem, tested it). I could argue that if the superuser says unlink it, he means it and the kernel should not forbid it. Regular users are protected from such folly. -- -- Art Zemon By Computer: ...!hplabs!felix!zemon By Air: Archer N33565 By Golly: moderator of comp.unix.ultrix