black (12/03/82)
I'm suprised that "Unix Wizards" are missing the difference between the three
different kinds of file deletion. They are:
(1) DeleteBody - i.e. make the file 0 bytes long
(2) DeleteEntry - An operation on a directory, not on the file
at all. The file is unchanged, but there is
one less directory entry which points to it.
(3) DeleteFile - Remove the file heading, as well as the body.
On unix, (1) is available by doing an open for reading and a close, and
requires write permission on the file to be DeleteBodied. (2) is available
by doing an Unlink on the directory concerned, and requires write permission
on the directory. So Unix does distinguish between these things rather well.
(3) is not available at all, on the other hand! I used to use a system where
it was available, and it was very handy. For example, if I have my own link
to a large system file, and the administrator creates a new version and
unlinks the old one, I am unaware of what has happened and continue to hog
disk space as well as use an out of date file. If the old file was
DeleteFile'd instead, when I next tried to access it I would get "Attempt to
Open Deleted File" and would thus be given a warning of what had happened.
If Unix was to add DeleteFile, then there is a strong argument for needing
different permissions to DeleteBody and to DeleteFile. However, I don't
beleive that it makes sense to make DeleteBody different from any other kind
of write.
Andrew Blackedwards (12/05/82)
#R:uw-beave:-23600:uicsovax:5500049:000:710 uicsovax!edwards Dec 4 21:58:00 1982 If the owner decides to recompile a program binary that you have a link to and he unlinks the file before the recompile, you WILL get stuck with the old copy. If your system administrator had just modified the files instead of unlinking them, you would have the updated copy. The thing I don't like about making a "delete file and all links" command is, when the owner cleans out his directory with that command removing your link too! Although, I can think of times when I would have liked something like that around. Alan Edwards (...!pur-ee!uiucdcs!uicsovax!edwards) P.S. There isn't anyway to know who has links to your files without traversing the whole filesystem is there?
Michael.Young.CMU-CS-A@SRI-UNIX@sri-unix (12/15/82)
From: Michael Wayne Young <Michael.Young.CMU-CS-A@SRI-UNIX> Date: 9 December 1982 1952-EST (Thursday) As I read about how people would like to have file deletion handled, I'd like to propose a slight change to our handling of files to allow for the DeleteFile ability, as well as other things like giving files away (without needing super-user-privileged chowns). What I'd like to see is a couple of special forms of file ownership: 1) Unowned. When you want to "give away" a file, you make a call like disown (filename). Nobody can then open the file until it is picked up with an take(filename) [or similar]. [There are problems with this: see below.] 2) Dead. When you want to DeleteFile something (that is, prevent ANY links to it from being used), you call destroy (filename), which then makes it "dead." As other links to this file are uncovered, the directory entries are removed (unless the filesystem is read-only, but this unlikely case just means the link's death is deferred). It's just as though the file wasn't there at all. Both of these can be implemented without any messing with the current inode structure... you just add two new "owners" from the uid pool. The advantage to "unowned" is that you can delete a file without really making its contents go away... for example, if you have disk quotas, you can give a file away to someone else with a link if you can't afford it. This can obviously be abused, as two users can just trade off ownership, but they'd have to be really careful about it [not to mention that their total quota could still not be exceeded]. It also has synchronization problems (i.e. who can take ownership after a file is disowned has to be well-thought out -- I'd recommend only allowing users with links to it [i.e. access to those links] to take a file). Still, a careful chown could be achieved by making a directory accessible only by the two parties involved somehow. Note that nobody could access an "unowned" file until it became "owned" (except for root, of course). You'd also want to let people to remove links from "unowned" files as well (and root can always remove them). Thus, an "unowned" file can disappear without anyone ever picking it up. Similarly, you can then "delete" a file permanently. Little added cost is involved, and the uses were explained in the note I'm answering. Yes, there are a few holes in my solution, but they can be ironed out (but I'd rather not spend the time here) fairly straightforwardly. I'd like to hear from anyone who has real difficulties with the idea, though. Michael