From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 13 Mar 2000 12:01:18 +0000
From: Roman Shaposhnick vugluskr@unicorn.math.spbu.ru
Subject: [9fans] Re: 9p question
Topicbox-Message-UUID: 9f570a74-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <20000313120118.sb9TXtL1v-OHc-4ClKlGPC-NgJjXqht2yb3LoiENExE@z>

On Fri, 10 Mar 2000 11:24:57 GMT, forsyth@caldo.demon.co.uk wrote:
>>>>>>I definitely can not understand why openness is persistent property in the
>>>>>>sense that when I clone the open fid the copy happens to be open too.
>>>>
>>>>clone(5) notes that ``The fid [to be cloned]... must not have been
>>>>opened for I/O by an open or create message''.
>
>>>  Well, I certainly can read man page. I ask why there is such limitation,
>>>not where and how it is described. Sorry, but I would like to discuss bare
>>>9P ( see my previous letter ).
>
>you asked why openness is persistent across clone, and i simply observed that it is not persistent and cannot be,
>because clone is expressly prohibited on an already open fid.  it therefore isn't true
>that when you `clone the open fid the copy happens to be open too'.

 No, may be it isn't true, but it isn't false either. I can not speak with
real P9 server for now, but u9fs allows me to clone open fids. Please see
the following:

>> Tstat tag 3 fid 1
<< Rstat tag 3 fid 1 + dir
>> Topen tag 4 fid 1 mode 0x0
<< Ropen tag 4 fid 1 qid 0x81000002.0x38788ddd
>> Tclone tag 5 fid 1 newfid 2
<< Rclone tag 5 fid 1

That's why I asked question about all that stuff.


>it seems you were really asking: why can't i clone an open fid?
>here is my view (not having actually designed the thing).
>
>the operation of Topen, in some file servers, leads to the creation of some server-side
>state (eg, the state implied by a file descriptor opened in an underlying operating system,
>in the case of u9fs, or as another example, the state created for an open directory to
>permit reading it), and that state might not be easily cloned, or not able to be cloned at all
>(what does it mean to `clone' a file descriptor's state in unix or a file handle's state in Nt?).
>by contrast, the current Tclone clones state that the server can control
>and understand completely (eg, local data structures).
>it's hard enough trying to implement some of the operations as it is!

 I believe, that this limitation is a Plan 9 issue not 9P. Something
like seek(2) on directories, that is possible in 9P and is forbidden in
Plan 9 due to the reasons mentioned here. That's my speculations, but
since gurus are not with us and it seems that they are not
interested we can not know for certain. :)

Thanks,
Roman.