[9fans] fsdirread v dirread()

[9fans] fsdirread v dirread()

[erik quanstrom]

i've been running linux 2.6.14 and mounting upasfs via
this mtab entry:

/tmp/ns.quanstro.:0/upasfs	/home/quanstro/9/upasfs	9P	uid=N,user,name=quanstro,proto=unix,noauto	0 0

which works great (after a few tweaks) except faces -i chokes and dies because
fsreaddir() ends up sending upasfs the path "/home/quanstro/upasfs/mbox/..."
instead of "mbox/...". i'm guessing that the named sockets in $NAMESPACE
need this extra information.

so, is there any way to modify faces so it doesn't care if it is given a mounted 
filesystem or a named socket in $NAMESPACE?

- erik

Re: [9fans] fsdirread v dirread()

[Russ Cox]

> i've been running linux 2.6.14 and mounting upasfs via
> this mtab entry:
>
> /tmp/ns.quanstro.:0/upasfs      /home/quanstro/9/upasfs 9P      uid=N,user,name=quanstro,proto=unix,noauto      0 0
>
> which works great (after a few tweaks) except faces -i chokes and dies because
> fsreaddir() ends up sending upasfs the path "/home/quanstro/upasfs/mbox/..."
> instead of "mbox/...". i'm guessing that the named sockets in $NAMESPACE
> need this extra information.

some more information would be helpful.
fsreaddir reads a directory.  it doesn't send paths.
what is the ... that you're eliding?

i am guessing that you are looking at loadmboxfaces.
the results of dirread are used in that loop, but
dirread is most definitely not the problem.

when you click on a face, faces sends a plumbing
message containing the message directory.
that message should contain the entire directory,
or else the program the plumber invokes will not
know how to handle it.

plumber in turn will run
    window -r 4 120 750 600 upas/nedmail -s $0
and given that there is no window script (yet),
that's going to fail.

you can see the plumbing messages by running
    9p read plumb/showmail
or maybe
    cat /home/quanstro/9/plumb/showmail
in another window.  check that the path is the full one.

then: does
    upas/nedmail -s /home/quanstro/9/upasfs/mbox/1/
work?  it should.  if not, figure out what nedmail is
doing wrong.

russ

Re: [9fans] fsdirread v dirread()

[erik quanstrom]

hopefully this is not to hurried.
the ... was /N/info where N is the message #.
i may have been wrong on the fsreaddir.

i have o.fs -m /home/quanstro/9/upasfs -b -d -s -f /imap/mail.speakeasy.org/quanstro
running. i'm reading 9p output from that.

the problem is that the 9p paths that faces sends upasfs when given 
-i -m /home/quanstro/9/upasfs/mbox as the mailbox start with 
"/home/quanstro/9/upasfs". upasfs returns an error that the file doesn't
exist and at that point in the code, faces exits. 

the magic incantation "faces -i -m mbox" works. upasfs doesn't get 
paths that start with "/home/quanstro/9/upasfs".

i hadn't gotten to nedmail yet.

erik

Russ Cox <rsc@swtch.com> writes

| 
| > i've been running linux 2.6.14 and mounting upasfs via
| > this mtab entry:
| >
| > /tmp/ns.quanstro.:0/upasfs      /home/quanstro/9/upasfs 9P      uid=N,user,name=quanstro,proto=unix,noauto      0 0
| >
| > which works great (after a few tweaks) except faces -i chokes and dies because
| > fsreaddir() ends up sending upasfs the path "/home/quanstro/upasfs/mbox/..."
| > instead of "mbox/...". i'm guessing that the named sockets in $NAMESPACE
| > need this extra information.

Re: [9fans] fsdirread v dirread()

[Russ Cox]

> the problem is that the 9p paths that faces sends upasfs when given
> -i -m /home/quanstro/9/upasfs/mbox as the mailbox start with
> "/home/quanstro/9/upasfs". upasfs returns an error that the file doesn't
> exist and at that point in the code, faces exits.

faces does not send anything to upas/fs.

when you start with -i, faces reads the upas/fs directory
and puts some faces on the screen.

when you click on a face, faces sends a plumbing message
to the plumber.  the plumber starts nedmail.

in neither case does a path get sent from faces
to upas/fs.

i finally see what you're talking about -- paths aren't
being sent to upas/fs.  they're being opened.
the ported faces code assumes that it is talking to a
9p service upasfs and not a mounted directory,
so it assumes that the path you've given it with -m is
fair game to use in the open request to upasfs.
so faces -i -m mbox is the right thing to use.

originally you said that faces -i was trying to open
paths like upasfs:/home/quanstro/9/upasfs/...,
but i don't see how that would happen.  faces -i
uses upasfs:/mail/fs/mbox by default, which
is still wrong, but not what you wrote.  it should
be using plain old upasfs:mbox.  apologies for
the clumsy syntax: by a:b i mean path b on 9p server a.

faces doesn't use the regular file system calls, so
it doesn't matter at all that you've got the upasfs
mounted somewhere by the operating system.
faces will just access the 9p service directly like it
would anywhere else.

russ