Re: [9fans] experimental change for devmnt to deal with spaces

[rog@vitanuova.com]

> What's the problem? Any of you must be aware of something I'm missing.

to continue with the upas/fs example, here's a function that opens a
mailbox and returns a pathname that can be used to access the messages
therein:

void
openmbox(char *path, char *name, char result[])
{
	fprint(open("/mail/fs/ctl", OWRITE), "open %q %q", path, name);
	sprint(result, "/mail/fs/%s", name);
}

imagine the function being called as follows:

{
	char buf[65536];
	openmbox("/mail/box/rog/mbox", "My\x00A0Mailbox", buf);
}

assuming upas/fs doesn't do the same character translation as the
mount driver, any subsequent code that tries to use the returned path
will fail, as the mailbox will have been created in upas/fs's internal
data structures *with* the 0xa0 character; however the mount driver
prevents that character from getting through.

to my mind, the fact that a pure plan 9 program has to be aware of
this convention to work correctly seems to indicate that the best
solution is at the boundaries of the system - i.e.  whereever a plan 9
fileserver interacts with an external name.

that keeps internal invariants simple, and the potential for peril low.

  rog.