Path: utzoo!attcan!uunet!husc6!cmcl2!lanl!unm-la!unmvax!turing.unm.edu!mike
From: mike@turing.unm.edu (Michael I. Bushnell)
Newsgroups: comp.unix.questions
Subject: Re: files with /
Keywords: filenames
Message-ID: <2093@unmvax.unm.edu>
Date: 15 Nov 88 01:15:00 GMT
References: <12589@steinmetz.ge.com>
Sender: news@unmvax.unm.edu
Reply-To: mike@turing.unm.edu (Michael I. Bushnell)
Organization: University of No Money, Albuquerque, New Mexico
Lines: 44

In article <12589@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:

>So how does the server create such a file?

[a file with '/' in the name]

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

Except that in the standard NFS implementation, the server IS the
kernel.  The server interacts with the filesystem below the pathname
traslation level.  

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

Except that the kernel doesn't have to talk to itself through the
syscall interface, and so it can bypass these sort of restrictions.
Look at the code: it actually *is* cleaner the way it is done.  It's
just that the clean semantics lead to an ugly bug.

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

Except that, once again, the kernel code IS the server.

>-- 
>	bill davidsen		(wedu@ge-crd.arpa)
>  {uunet | philabs}!steinmetz!crdos1!davidsen
>"Stupidity, like virtue, is its own reward" -me

Indeed.



                N u m q u a m   G l o r i a   D e o 

       \                Michael I. Bushnell
        \               HASA - "A" division
        /\              mike@turing.unm.edu
       /  \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike