You can keep srv() from eating Tattach's and Tauth's without numeric
userids with the following:
--- a/src/cmd/9pserve.c Wed Nov 03 15:49:22 2010 -0400
+++ b/src/cmd/9pserve.c Thu Nov 11 19:27:02 2010 -0800
@@ -440,6 +440,8 @@
m->tx.uname = getuser(); /* what srv.c
used */
repack(&m->tx, &m->tpkt, c->dotu);
}
+ if(dotu && !c->dotu)
+ repack(&m->tx, &m->tpkt, dotu);
break;
case Twalk:
if((m->fid = gethash(c->fid, m->tx.fid)) == nil){
@@ -474,6 +476,8 @@
continue;
}
m->afid->ref++;
+ if(dotu && !c->dotu)
+ repack(&m->tx, &m->tpkt, dotu);
break;
case Tcreate:
if(dotu && !c->dotu &&
(m->tx.perm&(DMSYMLINK|DMDEVICE|DMNAMEDPIPE|DMSOCKET))){
knieriem also proposed a fix at:
http://code.swtch.com/plan9port/issue/38/9pserve-not-translating-9p2000-client-msgs
Russ does this approach blow up your ssh-agent?
Noah
On Wed, Nov 10, 2010 at 6:31 AM, Russ Cox <r...@swtch.com> wrote:
>>> Factotum doesn't answer that message.
>>> You need to be looking at 9pserve.
>>
>> maybe i'm missing something, but 9pserve is also the
>> mechanism behind plumb, and it works. why would
>> p9serve be broken, but only for factotum? more likely
>> that drawterm itself is broken?
>
> It's always hard to say which program is broken
> when two programs can't talk to each other.
> I was only trying to point out that the two programs
> involved are drawterm and 9pserve, not drawterm
> and factotum (you had made changes to factotum
> in hopes that would fix it).
>
> I suspect the problem has to do with the so-called
> 9P2000.u protocol negotiation that 9pserve supports.
>
> Russ
>
>
