Hy there! (I'm quite new to the whole Plan 9 and 9P, so please
bare with me if I'm asking stupid or well known questions.) :)
Today I've introduced myself to the 9P protocol, and I've found it
very interesting. (I've reached it from the XCPU project.)
(And I must say that, in Linux, it could replace FUSE (File System
in User Space) for most use-cases.)
But after I've read (actually more skimmed through) the
documentation (man pages from 9p.cat-v.org) I've asked myself the
following questions and I thought that maybe the people on this
mailing list could help me better understand the problem / answers.
A) Why aren't there the following (POSIX) file operations: `move`,
`link` and `symlink` in the original 9p2000 protocol version?
Now I know that by using `wstat` I can change the name of a file,
but I can't move it outside the current directory.
I'm would say that all these three operations could be done by
using the 9p2000.u protocol extension to create. (For example a new
DMLINK type could be created that could act just like DMSYMLINK, but
create a "hard"-link instead, and in this way a move operation would
be just an link, then unlink operation, but by losing the atomicity
which could be required in certain contexts.)
(By the way, why isn't there such a DMLINK option for the extended
`create` operation?)
B) Also why isn't there a way to do meta-operations on files? For
example: application specific requests on file-id's?
Something like:
size[4] Tquery tag[2] fid[4] int[4](query-request-selector) input[s]
size[4] Rquery tag[2] fid[4] int[4](query-response-selector) output[s]
This would allow to implement things like ioctl's, or extended
attributes. Even more, someone could easily map HTTP requests over the
9p protocol, by asserting that after opening the file (which is the
path part of the URL), one should immediately call query to set
headers, then do a write (for the body), then do query (to obtain the
response headers), and then do read (for the response body). (Of
course another way to do this is to just write to the file headers
plus body just like in a normal HTTP stream, but this would imply
special parsing on the server side. Meanwhile with my solution, the
server will just ignore the query requests.)
Also I'm aware of the fact that I could (in theory) attach to a
different `aname`, one that would be the "meta-tree" of the actual
tree. And in here each file / directory in the real tree would have a
corresponding directory / sub-files that would allow me to do
meta-operations on the file-system. (Like moving, would be achieved by
writing a qid structure to a file named 'link' in the directory
corresponding to the real-directory, and then calling `remove` on the
real-tree. (Or something similar to this.)) But this solution (as
possible as it could be) it's cumbersome.
C) If I open a file for both reading and writing, why isn't there
a way to `clunk` (after some time) just the input part, or just the
output part? (Again would be usable in the case of the HTTP mapping,
when I don't know how much data the client is going to write as part
of the request body.)
Thank you all for your time,
Ciprian.
