From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200705031528.l43FSQ006268@zamenhof.cs.utwente.nl> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] tree problem In-reply-to: Your message of "Thu, 03 May 2007 11:01:46 -0400." <20070503150147.C2AAF1E8C1F@holo.morphisms.net> References: <20070503150147.C2AAF1E8C1F@holo.morphisms.net> From: Axel Belinfante MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6264.1178206105.1@zamenhof.cs.utwente.nl.cs.utwente.nl> Date: Thu, 3 May 2007 17:28:26 +0200 Topicbox-Message-UUID: 57286b80-ead2-11e9-9d60-3106f5b1d025 > > The solution may, alternatively be to register a clunk() > > function and each can do what they want with it though I > > do not like it because I feel I should receive things related > > with files and not with fids. > > the read and write requests you receive are for fids, > not files. you pull out the file using fid->file. > > you can use destroyfid to find out when a fid is > completely clunked. from 9p(2): > > Destroyfid > When a Fid's reference count drops to zero (i.e., it > has been clunked and there are no outstanding requests > referring to it), destroyfid is called to allow the > program to dispose of the fid->aux pointer. > > you can get at the file by using fid->file. at a time I had modified my local lib9p to be able to register a clunk function. I needed it for a 'filterfs' that sits between a user and another file server. it forwarded each incoming request (potentially modified) to the other file server, and handed back its responses (potentially modified) to the user. the forwarded requests contained the fids as given by the user. I needed to forward the clunk immediately, because otherwise the user might not be able to reuse a fid immediately after having clunked it (more accurately: if the user would do so, and the 'other' file server would not see the clunk before the reuse, there might be trouble.) Axel.