9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "nicolagi via 9fans" <9fans@9fans.net>
To: 9fans@9fans.net
Subject: Re: [9fans] 9P reading directories client/server behavior
Date: Wed, 10 Mar 2021 19:36:38 +0000
Message-ID: <202103101936.12AJageu014379@sdf.org> (raw)

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

             reply	other threads:[~2021-03-10 19:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 19:36 nicolagi via 9fans [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-03-09 14:05 nicolagi via 9fans
2021-03-09 20:01 ` Anthony Martin
2021-03-09 13:32 nicolagi via 9fans
2021-04-09 20:00 ` Russ Cox
2021-04-14 18:06   ` nicolagi via 9fans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202103101936.12AJageu014379@sdf.org \
    --to=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

9fans - fans of the OS Plan 9 from Bell Labs

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9fans

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9fans 9fans/ http://inbox.vuxu.org/9fans \
		9fans@9fans.net
	public-inbox-index 9fans

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9fans


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git