[9fans] Re: 9p question

[9fans] Re: 9p question

[Roman]

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.

[9fans] Re: 9p question

[presotto]

This is a multi-part message in MIME format.
--upas-hyltgcvlizbruhaurwogyusgdd
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

By the way, if you ftp, all the troff sources are under
plan9/man

--upas-hyltgcvlizbruhaurwogyusgdd
Content-Type: message/rfc822
Content-Disposition: inline

Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Mar  9 10:03:46 EST 2000
Received: from cse.psu.edu ([130.203.3.50]) by plan9; Thu Mar  9 10:03:46 EST 2000
Received: from localhost (majordom@localhost)
	by cse.psu.edu (8.8.8/8.8.8) with SMTP id JAA25319;
	Thu, 9 Mar 2000 09:49:49 -0500 (EST)
Received: by claven.cse.psu.edu (bulk_mailer v1.5); Thu, 9 Mar 2000 09:49:38 -0500
Received: (from majordom@localhost)
	by cse.psu.edu (8.8.8/8.8.8) id JAA25277
	for 9fans-outgoing; Thu, 9 Mar 2000 09:49:33 -0500 (EST)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81])
	by cse.psu.edu (8.8.8/8.8.8) with ESMTP id JAA25272
	for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 09:49:27 -0500 (EST)
Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1)
	id 12T42H-0001GS-00
	for 9fans@cse.psu.edu; Thu, 09 Mar 2000 14:35:33 +0000
Received: from GATEWAY by bath.ac.uk with netnews
	for 9fans@cse.psu.edu (9fans@cse.psu.edu)
To: 9fans@cse.psu.edu
Date: Thu, 9 Mar 2000 14:21:17 GMT
From: Roman Shaposhnick <vugluskr@unicorn.math.spbu.ru>
Message-ID: <slrn8cfcj2.8j3.vugluskr@unicorn.math.spbu.ru>
Organization: St.Petersburg University
References: <200003091318.IAA23349@cse.psu.edu>
Subject: Re: [9fans] Re: 9p question
Sender: owner-9fans@cse.psu.edu
Reply-To: 9fans@cse.psu.edu
Precedence: bulk

On Thu, 9 Mar 2000 13:36:51 GMT, presotto@plan9.bell-labs.com wrote:
>Mea culpa, mea culpa, mea maxima culpa.  My troff to html program doesn't
>do eqn.  Guess I'ld better eqn the pages before running em through.
>Thanks for Roman for noticing.

Dave,

and may be there is a chance to get troff sources ? Or this is restricted
by policy ?

Thanks,
Roman.
--upas-hyltgcvlizbruhaurwogyusgdd--

[9fans] Re: 9p question

[forsyth]

>> 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:

i'm fairly sure it's a mistake.  rclone should set nrf->busy, but didn't.
there's otherwise little point in the check made of rbusy
by rfilefid (or rclone itself come to that)
since only the rattach fid was busy.

[9fans] Re: 9p question

[Douglas]

Vladimir Prokopic wrote:
> Is there a chance to get awk?
> (Since the source of the true one is released
> or the port for Plan9 is restricted by policy ? )

What is wrong with using the one BWK made available on his Web page
(compile under APE)?

[9fans] Re: 9p question

[rob]

The source to awk has been available on Brian Kernighan's
web page "since the web was invented", according to him.

-rob

[9fans] Re: 9p question

[Vladimir]

--- Roman Shaposhnick <vugluskr@unicorn.math.spbu.ru> wrote:
> and may be there is a chance to get troff sources ? Or this is
> restricted
> by policy ?
>

--- presotto@plan9.bell-labs.com wrote:
> I'll put a tar out ther.
>

That's great.

Is there a chance to get awk?
(Since the source of the true one is released
or the port for Plan9 is restricted by policy ? )

Thanks,
Vladimir.
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

[9fans] Re: 9p question

[forsyth]

>>>>>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'.

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!

the decomposition of function within 9p (or styx) reduces the scope for unexpected interactions
and simplifies the semantics of the protocol's operations, which in turn, can potentially
simplify the implementation of both client and server.  larger actions are composed
of sequences of small, reasonably straightforward primitives.   having implemented
NFS clients and servers, i quickly came to appreciate the difference!

[9fans] Re: 9p question

[Roman]

On Thu, 9 Mar 2000 21:27:19 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 ).

Thanks,
Roman.

[9fans] Re: 9p question

[David]

rob pike <rob@plan9.bell-labs.com> wrote in message
news:200003091350.IAA23914@cse.psu.edu...
> > The real reason for the "lengthy" conversation is the Tclone/Twalk
> > part.  That is part of the price that is paid to remove the '/' as a
> > directory separator
>
> No.

Is that 'no' the conversation is lengthy, 'no' that it is part of the
price to remove '/' or 'no' that removing '/' was a goal?

[snip]
>elements (requiring the server to parse and understand '/'), but
>it's such a pain to change the protocol.

I hope if you though it "better" it would be worth the "pain".
(Not that I think it "better", I don't.)

[reorder]
>    The real reason is that after each walk the client must check whether
>the point-so-far is in the mount table.  That's why it's done a path

[snip]

>Seeking on a directory is forbidden because it's hard enough to
>implement reading a union directory without seek. The internal

By your own point union directories are handled in the Twalk.
What does that have to do with reading a directory?

>structure that must be maintained in the kernel was deemed too
>hard to maintain other than by sequential access, so we made
>seeking on a directory illegal.  It didn't seem worth the implementation
>overhad.

Back to the better/pain discussion, again.  I thought the limitations
to restrictive and worked out a better one.  Yes, it was painful, but
the result was well worth the effort.

>            I still feel that way.

I'm glad.  I won't have to integrate a conflicting solution when,
if ever, Release II(TM) sees the light of day...

[9fans] Re: 9p question

[forsyth]

>>  What do you mean by "Seeking on a directory" ? As stated in

seek(2) imposes the restriction.  the protocol doesn't know about
unions, mounts or anything else that might make such a restriction
convenient.

[9fans] Re: 9p question

[Roman]

On Thu, Mar 09, 2000 at 10:33:05AM -0500, presotto@plan9.bell-labs.com wrote:
> I'll put a tar out ther.

  Please let me know the exact location. I'm very eager to get the well
formated page for auth(6).

Thanks,
Roman.

[9fans] Re: 9p question

[Roman]

On Thu, 9 Mar 2000 14:08:23 GMT, rob pike wrote:
>> The real reason for the "lengthy" conversation is the Tclone/Twalk
>> part.  That is part of the price that is paid to remove the '/' as a
>> directory separator
>
>No. The real reason is that after each walk the client must check whether
>the point-so-far is in the mount table.  That's why it's done a path
>element at a time, and why it's so slow.  Other designs have been
>proposed that would allow a walk message to contain multiple
>elements (requiring the server to parse and understand '/'),

 I think this would be a very bad thing. From my point of view the main
strength of 9P is the fact that it allows one to manipulate a hierarchy
without bothering how names of the members are encoded. That's like you
have a partial ordered set and define elements via their relationship
between each other. I think this gives a maximum level of freedom in
how one would define a namespace.

>but it's such a pain to change the protocol.

  Oh, yes!

>Seeking on a directory is forbidden because it's hard enough to
>implement reading a union directory without seek.

  What do you mean by "Seeking on a directory" ? As stated in
manual ( read(5) ) "The read request message must have offset and count zero
modulo DIRLEN.". That's the only restriction. Also I see no restrictions
of reading from arbitrary offset in u9fs sources.

>The internal
>structure that must be maintained in the kernel was deemed too
>hard to maintain other than by sequential access, so we made
>seeking on a directory illegal.

 Hmm, I feel I should try to talk with real 9P servers instead of
u9fs.

>It didn't seem worth the implementation
>overhad.  I still feel that way.
>
>>There are a lot of strange things like:
>>     delim $$ define lbr ' roman "{" ' define rbr ' roman "}" '
>>or
>>     $CH sub c$
>>which should be "CH <sub>c</sub>",  I guess.
>
>Would you have noticed this if it didn't contain your name?

  With first capital letter ? No. :)

Thanks,
Roman.

[9fans] Re: 9p question

[presotto]

This is a multi-part message in MIME format.
--upas-cujudtopreocybipeuixodzphu
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

I'll put a tar out ther.

--upas-cujudtopreocybipeuixodzphu
Content-Type: message/rfc822
Content-Disposition: inline

Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Mar  9 10:03:46 EST 2000
Received: from cse.psu.edu ([130.203.3.50]) by plan9; Thu Mar  9 10:03:46 EST 2000
Received: from localhost (majordom@localhost)
	by cse.psu.edu (8.8.8/8.8.8) with SMTP id JAA25319;
	Thu, 9 Mar 2000 09:49:49 -0500 (EST)
Received: by claven.cse.psu.edu (bulk_mailer v1.5); Thu, 9 Mar 2000 09:49:38 -0500
Received: (from majordom@localhost)
	by cse.psu.edu (8.8.8/8.8.8) id JAA25277
	for 9fans-outgoing; Thu, 9 Mar 2000 09:49:33 -0500 (EST)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from mercury.bath.ac.uk (exim@mercury.bath.ac.uk [138.38.32.81])
	by cse.psu.edu (8.8.8/8.8.8) with ESMTP id JAA25272
	for <9fans@cse.psu.edu>; Thu, 9 Mar 2000 09:49:27 -0500 (EST)
Received: from news by mercury.bath.ac.uk with local (Exim 3.12 #1)
	id 12T42H-0001GS-00
	for 9fans@cse.psu.edu; Thu, 09 Mar 2000 14:35:33 +0000
Received: from GATEWAY by bath.ac.uk with netnews
	for 9fans@cse.psu.edu (9fans@cse.psu.edu)
To: 9fans@cse.psu.edu
Date: Thu, 9 Mar 2000 14:21:17 GMT
From: Roman Shaposhnick <vugluskr@unicorn.math.spbu.ru>
Message-ID: <slrn8cfcj2.8j3.vugluskr@unicorn.math.spbu.ru>
Organization: St.Petersburg University
References: <200003091318.IAA23349@cse.psu.edu>
Subject: Re: [9fans] Re: 9p question
Sender: owner-9fans@cse.psu.edu
Reply-To: 9fans@cse.psu.edu
Precedence: bulk

On Thu, 9 Mar 2000 13:36:51 GMT, presotto@plan9.bell-labs.com wrote:
>Mea culpa, mea culpa, mea maxima culpa.  My troff to html program doesn't
>do eqn.  Guess I'ld better eqn the pages before running em through.
>Thanks for Roman for noticing.

Dave,

and may be there is a chance to get troff sources ? Or this is restricted
by policy ?

Thanks,
Roman.
--upas-cujudtopreocybipeuixodzphu--

[9fans] Re: 9p question

[Roman]

On Thu, 9 Mar 2000 11:12:43 GMT, forsyth@caldo.demon.co.uk wrote:
>>>I can always issue as many Tstat as I would like. What wrong with
>>>letting length represent the number of directory entries  ?
>
>many interesting directories are generated on-the-fly (indeed that's the
>normal case for devices).   any size that could be
>given for any directory is at best a hint, and it is hard to see how to put
>it to any essential use.

 Just like with normal or, well, quasi-normal files. There is no any doubt
that this can be done just the same way. Or can not ?

>consequently, having to run through the generation
>code just to produce a less-than-useful size seems a bit of a waste
>of time.

 Yes, I understand your point, but my question was why the behavior is
inconsistent? I do not believe that for most files served by the file server
the size is zero, just because it seems to be so easy and natural to
fill the proper field with the file size when it is known and to put
there a special value when it is not.

>i made the extra effort in an operating system of my own,
>but i didn't find it especially worthwhile.

 It is not, especially when it is an exception, not the rule. IMHO, as always.

>it's worth noting that there are plenty of files in Plan 9 that can be read
>but have length set to zero (for much the same reason).
>the conventions are not completely consistent in practice,
>possibly caused by differing authors or changing
>priorities: compare {ls -l /dev/time} and {ls -l '#r/rtc'}.

  May be that's the answer. Different attitudes. I think this can explain
a lot. But I hope that there is a different answer. Will wait. :)

Roman.

[9fans] Re: 9p question

[Roman]

On Thu, 9 Mar 2000 13:36:51 GMT, presotto@plan9.bell-labs.com wrote:
>Mea culpa, mea culpa, mea maxima culpa.  My troff to html program doesn't
>do eqn.  Guess I'ld better eqn the pages before running em through.
>Thanks for Roman for noticing.

Dave,

and may be there is a chance to get troff sources ? Or this is restricted
by policy ?

Thanks,
Roman.

[9fans] Re: 9p question

[rob]

> The real reason for the "lengthy" conversation is the Tclone/Twalk
> part.  That is part of the price that is paid to remove the '/' as a
> directory separator

No. The real reason is that after each walk the client must check whether
the point-so-far is in the mount table.  That's why it's done a path
element at a time, and why it's so slow.  Other designs have been
proposed that would allow a walk message to contain multiple
elements (requiring the server to parse and understand '/'), but
it's such a pain to change the protocol.

Seeking on a directory is forbidden because it's hard enough to
implement reading a union directory without seek. The internal
structure that must be maintained in the kernel was deemed too
hard to maintain other than by sequential access, so we made
seeking on a directory illegal.  It didn't seem worth the implementation
overhad.  I still feel that way.

>There are a lot of strange things like:
>     delim $$ define lbr ' roman "{" ' define rbr ' roman "}" '
>or
>     $CH sub c$
>which should be "CH <sub>c</sub>",  I guess.

Would you have noticed this if it didn't contain your name?

-rob

[9fans] Re: 9p question

[presotto]

Mea culpa, mea culpa, mea maxima culpa.  My troff to html program doesn't
do eqn.  Guess I'ld better eqn the pages before running em through.
Thanks for Roman for noticing.

[9fans] Re: 9p question

[forsyth]

>>I can always issue as many Tstat as I would like. What wrong with
>>letting length represent the number of directory entries  ?

many interesting directories are generated on-the-fly (indeed that's the
normal case for devices).   any size that could be
given for any directory is at best a hint, and it is hard to see how to put
it to any essential use.  consequently, having to run through the generation
code just to produce a less-than-useful size seems a bit of a waste
of time.

i made the extra effort in an operating system of my own,
but i didn't find it especially worthwhile.

it's worth noting that there are plenty of files in Plan 9 that can be read
but have length set to zero (for much the same reason).
the conventions are not completely consistent in practice,
possibly caused by differing authors or changing
priorities: compare {ls -l /dev/time} and {ls -l '#r/rtc'}.

[9fans] Re: 9p question

[forsyth]

>>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''.

[9fans] Re: 9p question

[Douglas]

Roman Shaposhnick wrote:
> There are a lot of strange things like:
>      delim $$ define lbr ' roman "{" ' define rbr ' roman "}" '
> or
>      $CH sub c$
> which should be "CH <sub>c</sub>",  I guess.

Yes, those are "eqn" constructs, presumably not processed into HTML
because HTML lacks a good equation sublanguage.

[9fans] Re: 9p question

[Roman]

On Tue, Mar 07, 2000 at 09:32:30AM +0000, David Butler wrote:
> Roman Shaposhnick <vugluskr@unicorn.math.spbu.ru> wrote in message
> news:slrn8c7lt4.c7k.vugluskr@unicorn.math.spbu.ru...
> > On Tue, 29 Feb 2000 09:29:38 GMT, David Butler wrote:
> > >Roman Shaposhnick <vugluskr@unicorn.math.spbu.ru> wrote in message
> > >news:slrn8bfrif.u5c.vugluskr@unicorn.math.spbu.ru...
>
> > To be more precise there are several things that can not stop bothering
> me:
> >
> >     1. I still consider the Tclone/Topen/Tread/Tclunk a bit lengthy, and
> >     still can not understand limitations of why we can not walk opened
> >     fids.
>
> If Twalk was allowed on an open fid, (assuming it is a directory,
> because if it is a file it doesn't make any sense) does that mean
> you are done reading the directory?

   No this is not always true since I could be interested in some particular
property of each file in the directory. That's why I wonder why I should read
the whole directory or clone fids pointing to it but not being opened, when
I can just issue Twalk message.

> If you are, you should release
> the resources keeping track of the open context, so you still need a
> Tclunk.  Perhaps you would need a new clunk that says "leave the
> fid pointing to the directory, so I can walk it".

   Let me put it this way: I suspect that there is a good reason why I can not
Twalk into open directory ( though there was no clean explanation yet ) but
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.

> That would be like
> a clunk/walk.  Instead of doing that, why don't you simply have a
> Tclunk and a Tclwalk?  In other words, the result is the same.

  I understand. Moreover, I have elaborated workaround ( or may be the only
one correct solution ) that is exactly what are you talking of. But I still
can not understand the roots of this extra limitations. Why ? Why are they
there -- that's my only question.

> The real reason for the "lengthy" conversation is the Tclone/Twalk
> part.  That is part of the price that is paid to remove the '/' as a
> directory separator, which IMHO is a good thing.

  That's right. And that's the thing that I understand quite well. I can say,
that this is the one of the features that makes 9P very nice and powerful and
forces one to "think different" (tm) :). That's like Lisp. You can not think
the old pascal-c-fortran-algol way when you use it. Very refreshing and
enjoyable feeling.

> >     2. Why directories have a conventional length of 0? IMHO, it is very
> >     annoying, since the only way to know the exact number of
> >     directory entries is to read it up to the end.
>
> There is more to the issue than just the 0, though.  Directories in
> Plan9 have no "holes" (according to the protocol) and can NOT
> be seek(2)ed into.

   Hmm. That sounds strange. As stated in read(2) I could read from any
offset any number of bytes with the only one restriction: "The read
request message must have offset and count zero modulo DIRLEN". Are you
talking about seek(2) beyond the "end" of directory ?

> In other words, you can ONLY sequentially read a directory.

  I guess not, or may be I can not get what are you talking about.

> The theory breaks down real fast when you read
> a directory that concurrently has creates and removes occurring.
> I've seen ls(1) both list file names twice and not show files that
> actually exist!

   Hmm. It depends of how do you think of this :). I guess that ls(1)
lists the exact contents of the directory, or, being more precise,
the partial snapshot taken at that particular moment. But nevertheless,
this is just the same behavior that you can see with a set of concurrent
readers and writers of the plain file with one exception that you can not
lock directory. Or can you ?

> What is more interesting is that the behavior is
> different between file servers implemented in the cpu/terminal
> kernel vs kfs or "the file server".  In my system I've made them
> consistent and fixed the dup/missing names by making directories
> seekable (to a point.  seek(fd, n, 2) == seek(fd, n, 0) because the
> length of a directory is still 0, as it should be).

   Why ? Why it should be 0. Because the length can change after Tstat ?
Well, that's ok. That's just the situation with a plain file. Moreover,
I can always issue as many Tstat as I would like. What wrong with
letting length represent the number of directory entries  ?

> > available info would be enough for me. By the way, why htmled man pages
> > have a lot of HTML errors ? If  this is a bug, then may be somewhere there
> > is a site with P9 htmled man pages that I can read, not decode ?
>
> Since Plan9 is copyrighted and there are no other distributors of the
> system commercially, the manuals can only be seen on bell-labs site
> from the web.

  Oh-no. Bad news.

> I don't see any formating issues with section 5 of the
> manual (where 9P is documented) so I don't know why you would
> have a problem.  Perhaps you could give a URL of a problem page?

  Sure. Here it is: http://inferno.bell-labs.com/magic/man2html/6/auth.

There are a lot of strange things like:
     delim $$ define lbr ' roman "{" ' define rbr ' roman "}" '
or
     $CH sub c$
which should be "CH <sub>c</sub>",  I guess.


Thanks,
Roman.

[9fans] Re: 9p question

[David]

Roman Shaposhnick <vugluskr@unicorn.math.spbu.ru> wrote in message
news:slrn8c7lt4.c7k.vugluskr@unicorn.math.spbu.ru...
> On Tue, 29 Feb 2000 09:29:38 GMT, David Butler wrote:
> >Roman Shaposhnick <vugluskr@unicorn.math.spbu.ru> wrote in message
> >news:slrn8bfrif.u5c.vugluskr@unicorn.math.spbu.ru...

> To be more precise there are several things that can not stop bothering
me:
>
>     1. I still consider the Tclone/Topen/Tread/Tclunk a bit lengthy, and
>     still can not understand limitations of why we can not walk opened
>     fids.

If Twalk was allowed on an open fid, (assuming it is a directory,
because if it is a file it doesn't make any sense) does that mean
you are done reading the directory?  If you are, you should release
the resources keeping track of the open context, so you still need a
Tclunk.  Perhaps you would need a new clunk that says "leave the
fid pointing to the directory, so I can walk it".  That would be like
a clunk/walk.  Instead of doing that, why don't you simply have a
Tclunk and a Tclwalk?  In other words, the result is the same.

The real reason for the "lengthy" conversation is the Tclone/Twalk
part.  That is part of the price that is paid to remove the '/' as a
directory separator, which IMHO is a good thing.

>     2. Why directories have a conventional length of 0? IMHO, it is very
>     annoying, since the only way to know the exact number of
>     directory entries is to read it up to the end.

There is more to the issue than just the 0, though.  Directories in
Plan9 have no "holes" (according to the protocol) and can NOT
be seek(2)ed into.  In other words, you can ONLY sequentially
read a directory.  The theory breaks down real fast when you read
a directory that concurrently has creates and removes occuring.
I've seen ls(1) both list file names twice and not show files that
actually exist!  What is more interesting is that the behavior is
different between file servers implemented in the cpu/terminal
kernel vs kfs or "the file server".  In my system I've made them
consistent and fixed the dup/missing names by making directories
seekable (to a point.  seek(fd, n, 2) == seek(fd, n, 0) because the
length of a directory is still 0, as it should be).

> available info would be enough for me. By the way, why htmled man pages
> have a lot of HTML errors ? If  this is a bug, then may be somewhere there
> is a site with P9 htmled man pages that I can read, not decode ?

Since Plan9 is copyrighted and there are no other distributors of the
system commercially, the manuals can only be seen on bell-labs site
from the web.  I don't see any formating issues with section 5 of the
manual (where 9P is documented) so I don't know why you would
have a problem.  Perhaps you could give a URL of a problem page?

[9fans] Re: 9p question

[rob]

The Topen message generates a permission check and enables I/O. Before
the open, you may not read or write on the fid.  There is no close (well, there
is, but it's called clunk) because you must dispose of fids that have not been
Topened, so it seemed that Tclose would be the wrong name for the operation.

The manual says somewhere I believe, and the code says somewhere I know,
that once a fid is opened, it cannot be walked or cloned further.  This avoids
some difficult implementation problems for the servers.

-rob