[9fans] Re: 9p question

[Roman Shaposhnick vugluskr@unicorn.math.spbu.ru]

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.