Path: utzoo!attcan!uunet!husc6!ukma!mailrus!ulowell!arosen@hawk.ulowell.edu
From: arosen@hawk.ulowell.edu (MFHorn)
Newsgroups: comp.protocols.nfs
Subject: Re: Yes, Virginia, you *can* have UNIX filenames containing '/'
Message-ID: <10176@swan.ulowell.edu>
Date: 12 Nov 88 19:26:29 GMT
References: <5945@fluke.COM>
Sender: news@swan.ulowell.edu
Lines: 29

From article <5945@fluke.COM>, by jeff@tc.fluke.COM (Jeff Stearns):
> Most of us think of '/' as a separator in Unix pathnames, but it ain't
> always so.  I just created several files with '/' in the filenames
> themselves.
> 
> It's remarkably easy to do - just cook up an NFS packet with the
> appropriate bits in it.  NFS servers don't care; they're not responsible
> for parsing pathnames, so they don't know about separators.  They deal
> only in individual filenames.  If an NFS client wants to name a file
> "//./..///", that's fine with the server.  Into the directory it goes.

So how does the server create such a file?

The server has to ask the kernel (via syscalls, like everyone else)
to create the file for it.  The kernel parses every filename it's
given through the magic of lookupname().  That's why you can just
say open("/foo", O_RDWR), instead of open(devnum, inum, O_RDWR).

In the above case, the kernel would get open("//./..///", O_RDWR|O_CREAT),
or something similar, try to open "/" for write and fail with EISDIR.

It's possible that the RPC system calls are stupid (ie. they don't
use lookupname); I've never seen kernel code for RPCs.  If so, then
this is where the bug is, not in the server code.

Andy Rosen           | arosen@hawk.ulowell.edu | "I got this guitar and I
ULowell, Box #3031   | ulowell!arosen          |  learned how to make it
Lowell, Ma 01854     |                         |  talk" -Thunder Road
		RD in '88 - The way it should've been