Apple ][/II/2

There's been a lot of sloppy terminology floating around in this thread, and have some little expertise in the area - I've been doing system programming, on each side of the user/kernel divide, for decades, and I wrote my own user-land code to read a popular Unix filesystem.... "Filename" is an ambiguous term. The Unix file APIs traditionally have exactly two special byte values: 0x00 and '/'. The former is a string terminator; the latter is a pathname component separator. While it can look sort of as though you can use a / in pathnames by creating directories, it's a rather poor emulation; put a slash at the beginning or end of your "filename", or try to use two consecutive slashes as distinct from just one, and the fiction that you're using a / as just another character in a filename falls apart fast. That said, there _are_ some circumstances under which some systems will let a / sneak into a pathname component at some level. Some NFS server implementations do not do such checking, depending on the client to do it if it's to be done at all, and NFS clients that aren't traditional Unices can "offend" in this regard. (The example I've usually seen cited is Macs from the HFS days, before OS X moved to Unix APIs; they used : as a pathname separator, with / as an ordinary character. I've seen it said that more recent NFS clients for them swap : and / in the client code to avoid exactly this problem with Unix NFS servers.) But such "filenames" aren't usable on the server even when created, since the Unix APIs generally treat / as a pathname separator rather than a pathname component character, even when pathname components containing slashes exist. (You can get them out, with things like ls, but anything that passes string pathnames into the kernel can't touch them. Some systems have APIs, designed for use by things like NFS servers, that can let you at them, but they're difficult to use and usually require privileged access anyway.) It would be possible to design an alternative API, such something based on counted lists of counted strings, that did not have any reserved octet values. This could work to a point, but code that used the additional capabilities this provided would produce on-disk data not usable through the older APIs. Backslashes are not special to the filesystem in any Unix I know of. But they *are* special to the shell; to pick an example I've seen mentioned upthread, "touch \/path" to most shells is equivalent to just "touch /path", because the \ is treated by the shell as quoting the /, which doesn't do anything because / is not special to the shell. (By the time touch gets the pathname and passes it off to the kernel, the quoting has been lost; touch has no way to tell that the / was quoted at the shell level.) If you double the \ to get it past the shell, or you use some interface to which \ is not special, then \/path is a thing named "path" in a directory named "\", just as a/bcde is a thing named "bcde" in a directory named "a". /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B