Re: [9fans] Ephase question.

[presotto@plan9.bell-labs.com]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

We chose it because it was easier to implement and we couldn't see
that doing so would cause undo hardship.  Rsc's observation is good
but wasn't really a design goal.

There are 3 obvious alternatives:
- Unix' solution of making the remove fail with "file busy"; it was
always inconvenient and confusing.  They use that one for in use
executables.  The fs doesn't really know when a file is executing so that
one isn't really that useful to us.
- Have the remove work but not really remove the file from the directory
till the current opener goes away.  That's just too confusing.
- Disassociate the file with the directory, but leave it around for anyone
that has it open to keep playing with.  This is easy to do when the
file is really represented by an inode that doesn't have anything to
do with a directory.  It's a lot harder without that indirection.  We
didn't have inodes.  The best we could do is copy it somewhere else
and fudge up pointers to the somewhere else (a special invisible
directory perhaps).  It also leads to cleaning up orphaned files
during a reboot of the file server, fsck's job (or one of many) in
Unix.  It gets messy quick without inodes being the one true
representation.

Clearly its a matter of taste; with enough code you can do most
anything.  If it were a goal, Ken would proabably have designed
his fs a bit differently.  Our taste, like our minds, tends to
favor the simple.  Of course, we're gradually losing our sense
of taste due to exigency. About time for a new simple operating
system.

[-- Attachment #2: Type: message/rfc822, Size: 4885 bytes --]

From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Ephase question.
Date: Tue, 13 Aug 2002 07:14:22 +0400
Message-ID: <20020813071422.A12044@unicorn.math.spbu.ru>

On Mon, Aug 12, 2002 at 09:39:40PM -0400, presotto@plan9.bell-labs.com wrote:
> This isn't new semantics.  If you remove a file that someone
> else is using, too bad for him.  There's nothing sacred about
> having a file open.

  Indeed. Same applies to any fid, not just opened ones.

> If someone else has permissions to do nasty and nefarious things to it,
> they can.
>
> This is very different than Unix.

  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.

Thanks,
Roman.

> Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Mon Aug 12 21:27:18 EDT 2002
> Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Mon Aug 12 21:27:17 EDT 2002
> Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
> 	id 04B4D199B9; Mon, 12 Aug 2002 21:27:07 -0400 (EDT)
> Delivered-To: 9fans@cse.psu.edu
> Received: from unicorn.math.spbu.ru (unicorn.math.spbu.ru [195.19.226.166])
> 	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 4D5C41998C
> 	for <9fans@cse.psu.edu>; Mon, 12 Aug 2002 21:26:20 -0400 (EDT)
> Received: (from vugluskr@localhost)
> 	by unicorn.math.spbu.ru (8.9.3/8.9.3) id FAA10626
> 	for 9fans@cse.psu.edu; Tue, 13 Aug 2002 05:26:18 +0400
> From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
> To: 9fans@cse.psu.edu
> Message-ID: <20020813052618.A10336@unicorn.math.spbu.ru>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> X-Mailer: Mutt 1.0pre3i
> Subject: [9fans] Ephase question.
> Sender: 9fans-admin@cse.psu.edu
> Errors-To: 9fans-admin@cse.psu.edu
> X-BeenThere: 9fans@cse.psu.edu
> X-Mailman-Version: 2.0.11
> Precedence: bulk
> Reply-To: 9fans@cse.psu.edu
> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
> List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
> Date: Tue, 13 Aug 2002 05:26:18 +0400
>
> Hi everybody,
>
> digging inside 4th edition gave me some very unexpected results
> in terms of file access semantics in user space. But let me show
> a scenario first:
>
> first-user$ cat > /shared-directory/file
> blah-blah-blah
>
> second-user$ rm /shared-directory/file
>
> [first user after hitting <CR> ]
> "phase error -- directory entry not allocated"
>
> I was a little bit shocked at first, mainly because I've got so used to
> UNIX semantics of "once you get it -- it's yours", that I've been taking
> it for granted in Plan9 as well.
>
> Suddenly I can't remember how 3nd and 2nd editions behaved.
>
> Before now I was under the impression that regular unopened fids are mostly
> used for reference counting and once you grab a fid nobody can kill the
> actual object it refers to, but 4th edition proved me wrong. Even though
> I still can't understand why it behaves this way. Could somebody explain
> the rationale behind that to me, please ? And I'm really curios now about
> what obligations server is supposed to have when it accepts a new fid from
> a client for a given object.
>
> Thanks,
> Roman.