From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <29e05aa2f218db4017cf95233091743f@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Ephase question.
From: "rob pike, esq." <rob@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon, 12 Aug 2002 23:37:51 -0400
Topicbox-Message-UUID: db2d1fb4-eaca-11e9-9e20-41e7f4b1d025

>   I see. But can you give me any insight into why it was implemented this
>   way. Again, it seems so obvious to use fids for reference counting and it
>   shouldn't be of a significant overhead. Moreover it's entirely up to
>   the FileServer to support this feature -- kernel is not supposed to
>   care. You should've had some reason for not supporting this in all
>   your FileServers.

There was an implementation reason, which I don't remember.  I prefer
this argument:

	When you remove a file, it's removed.

That's the definition of remove, as I understand it.

Unix has a weird property that you can remove files and they're still not
removed until some unfindable process dies.  We used to run out of disk
space because an editor (mine) unlinked its /tmp file so it wouldn't clutter the
disk if it exited prematurely.  If someone edited a big file, /tmp would fill
up but ls /tmp wouldn't tell you anything.  Not to mention what happens
if the kernel crashed with a file in that half-made state.

open(ORCLOSE) is a much cleaner solution to the /tmp problem.

But the real argument is that Unix's semantics are an accident of the way
it implemented its file system.  Plan 9 has different semantics.  Whether
or not it's what you want, it's hard to argue with:

	When you remove a file, it's removed.


-rob