From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roman V. Shaposhnick" To: 9fans@cse.psu.edu Subject: Re: [9fans] Ephase question. Message-ID: <20020813071422.A12044@unicorn.math.spbu.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Date: Tue, 13 Aug 2002 07:14:22 +0400 Topicbox-Message-UUID: db0aea0c-eaca-11e9-9e20-41e7f4b1d025 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" > 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: > 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 ] > "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.