Re: [9fans] 9P reading directories client/server behavior

["nicolagi via 9fans" <9fans@9fans.net>]

Quoting Anthony Martin <ality@pbrane.org>:
> nicolagi via 9fans <9fans@9fans.net> once said:
>> The only question that still stands is the last in my original post:
>> What happens and what should happen when a dir entry is larger than
>> msize-24? Possibly written from a connection with a large msize, and to
>> be read from a connection with a smaller msize?
> 
> In that case either the server or client lied about it's
> msize and is not correctly speaking the 9p protocol.
> 
>>From version(5):
> 
>         The client suggests a maximum message size, msize, that is
>         the maximum length, in bytes, it will ever generate or ex-
>         pect to receive in a single 9P message. This count includes
>         all 9P protocol data, starting from the size field and ex-
>         tending through the message, but excludes enveloping trans-
>         port protocols. The server responds with its own maximum,
>         msize, which must be less than or equal to the client's
>         value. Thenceforth, both sides of the connection must honor
>         this limit.

Different clients can still negotiate different values for msize.
I've written a program to show that the scenario I'm talking about
is real.  Here's the trace that shows creating a file with an absurdly
large name (name omitted):

        Tversion msize 131072 version '9P2000'
        Rversion msize 131072 version '9P2000'
        Tattach fid 1 afid 4294967295 uname 'nicolagi' nuname 4294967295 aname ''
        Rattach aqid (16061c98c25a5b1c 1 'd')
        Twalk fid 1 newfid 2 0:'tmp' 
        Rwalk (16061c9a5c4069e4 1 'd') 
        Tcreate fid 2 name 'ality.OMITTED' perm 666 mode 0 
        Rcreate qid (166b10d3f614e29e 1 '') iounit 0
        Tclunk fid 2
        Rclunk

Listing using a connection with msize 8192 and grepping the new file:

        ; 9p ls pine/tmp | grep ality | wc -l
        0

I can create another file after the absurdly named one, but I can't
list it, because the client wrongly detects EOF before reaching that:

        ; date > another
        ; ls | grep another | wc -l
        0

You can see why I thought a server may return Rerror instead of silently
clipping the listing.  But it's fine, nobody will generate such large
dir entries, I was just confused to find this edge case and around how
to handle it.

I'll go write some client code to clean up my tmp folder now. :-)


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T65a81624b7b9db0f-Mf45bcfc5bcd0d01d25fda0e1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription