> 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
