From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 7 Mar 2000 09:32:30 +0000 From: David Butler gdb@dbsystems.com Subject: [9fans] Re: 9p question Topicbox-Message-UUID: 9e97b764-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <20000307093230.rUkjkwPbuf2Aky0c-yqjdLEsCcufJPLYpDvbs_WoH4s@z> Roman Shaposhnick 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 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?