From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] experimental change for devmnt to deal with spaces
From: rog@vitanuova.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20020703213236.7E3AD19A0D@mail.cse.psu.edu>
Date: Wed,  3 Jul 2002 22:38:24 +0100
Topicbox-Message-UUID: c10e9aa4-eaca-11e9-9e20-41e7f4b1d025

> 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.