From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 9P2000
From: rog@vitanuova.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010130110451.132A3199F7@mail.cse.psu.edu>
Date: Tue, 30 Jan 2001 12:09:14 +0000
Topicbox-Message-UUID: 54789c4c-eac9-11e9-9e20-41e7f4b1d025

ducky.net!mike wrote:
> (B) the byte count of the directory entry might result
> in the required size of the Rread message exceeding the negotiated
> maximum transaction size between the 9P client and server.
[...]
> Scenario (B) is bad.  There is no easy way for the client to recover.
> Certainly the client application can do nothing about it: the protocol
> connection is already established and the msize is fixed in stone.

my understanding was that if a client tried to negotiate a message size
that was too small for the server's maximum filename size, the server
would yield an Rerror "message size too small" or somesuch.

this, perhaps, would be one reason to allow multiple Tversions - if a
Tversion has resulted in an Rerror, then surely it should be possible
to negotiate another version or msize.

there's one case where the client has to be a bit careful about the
size of messages it generates. a Twalk message can itself fit inside
the negotiated msize, but require an Rwalk that will not do so. (e.g.
walking down several short pathname elements).  it might be worth
requiring a minimum message size of 1+4+2+2+MAXWELEM*13 = 217 which
would avoid this problem.

> Assuming the server does *not* reject truncation of a directory to
> length 0, should a client assume that all files under the directory
> have been removed? This is another one of those possible complications
> that I think should be eliminated by specifying them out of the
> protocol: always reject attempts by wstat to change the length of
> a directory.

a directory has a conventional length of 0 anyway, so it would make
sense if setting the length of a directory to zero was a no-op.

> If the walk operation fails, does newfid exist (and point to the
> same qid as fid), or is it implicitly clunked?

and quoted previously:

> > Also, nqid will always
> > be less than or equal to nwname.  Only if it is equal, how-
> > ever, will newfid be affected, in which case it will repre-
> > sent the file reached by the final elementwise walk
> > requested in the message.

i.e. if the walk operation fails, newfid is not affected (created or
walked).

  cheers,
    rog.