Thanks for your answer.
On Saturday, 5 November 2022, at 3:09 PM, ori wrote:
> The Tflush was successful: The Rflush does not indicate that a message was
cancelled, tit indicates that the server is no longer processing the request.
After your answer an read the manual pages a few times again and
Quoth ibrahim via 9fans <9fans@9fans.net>:
> tflush is also used to interrupt pending requests in user-file-systems. And
> there such a situation can happen where you can't respond to a Tflush. The
> server already processed the message for noldtag and sent its reply. Now you
> can't reply to a
Thank you for your clarifications Ori. From the perspective of kernel
filesystems what you wrote made things clear. But one question remains
regarding tflush and user fileservers :
On Saturday, 5 November 2022, at 5:31 AM, ori wrote:
> This situation is impossible -- you can always respond to a
Quoth ibrahim via 9fans <9fans@9fans.net>:
> On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote:
> > I'd argue that this may be the most real-world-tested Tflush handler you'll
> > see. I have seen Tflush handlers that just return, having done nothing, and
> > it's possible that in
On Saturday, 5 November 2022, at 12:41 AM, ron minnich wrote:
> I'd argue that this may be the most real-world-tested Tflush handler you'll
> see. I have seen Tflush handlers that just return, having done nothing, and
> it's possible that in many cases, that's good enough. But Chris's code is
>
Thanks for your reply Ron.
At least now I know that Tflush and Tversion in the middle of a running session
can really be beasts and this wasn't only my imagination.
I'm writing three filesystems for my applications needs. For the first the
whole tflush, tversion (which is far more dangerous
Tflush is harder than it looks, given that it is part of a giant race
condition. Will you get the R for the message you are flushing right after
you send Tflush? What happens at the server? It's fun.
Perhaps one of the biggest uses of 9p, globally, was google's gvisor, which
runs an unimaginably
I have read the manuals and also searched for this question here without
finding an answer (perhaps I missed it) :
1) question about flush :
Lets say there was a pending message with tag=1234 and the client of my server
sent a flush message with a tag=1450. During the travel of the flush the
I can't find details on the file execution permission: looks like a
malicious client could just ignore it on files and execute anything that it
can read (obviously I'm just talking about single files, not directory).
It's not malicious, just incorrect. Obviously you can't execute a
Hi, I'm coding a small .NET library to connect 9p2000 services and I have a
few questions about things that the manual doesn't explain (or I was not
able to find).
What's the meaning of qids? I see that responses often include them but
request messages do not.
What's the proper message sequence
On 29 January 2015 at 09:04, Giacomo Tesio giac...@tesio.it wrote:
What's the meaning of qids? I see that responses often include them but
request messages do not.
see intro(5) or intro(9P) depending on system. They identify a file on
a server; they are a value provided by the server to
What's the proper message sequence to delete a file? And to delete a non
empty directly?
You point a fid at the file, then remove it:Twalk* ... Tremove
A non-empty directory can't be removed.
Tremove implies Tclunk
the current on-disk file servers do follow this rule, but
Il 29/Gen/2015 11:12 Charles Forsyth charles.fors...@gmail.com ha
scritto:
On 29 January 2015 at 09:04, Giacomo Tesio giac...@tesio.it wrote:
What's the meaning of qids? I see that responses often include them but
request messages do not.
see intro(5) or intro(9P) depending on system.
size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s]
size[4] Rattach tag[2] qid[13]
you have to provide the afid in the Tattach, so clunking it before
attach makes no sense. you can pass NOFID to Tattach when when the
fileserver doesnt support authentification.
you can
Actually I wasn't able to understand when the afid was supposed to be clunk
reading attach 5.
I was in doubt that the afid had to be the last fid clunked.
Giacomo
Il 29/Gen/2015 15:56 cinap_len...@felloff.net ha scritto:
size[4] Tattach tag[2] fid[4] afid[4] uname[s] aname[s]
15 matches
Mail list logo
