Path: utzoo!attcan!uunet!steinmetz!davidsen From: davidsen@steinmetz.ge.com (William E. Davidsen Jr) Newsgroups: comp.unix.questions Subject: files with / Keywords: filenames Message-ID: <12589@steinmetz.ge.com> Date: 14 Nov 88 16:01:50 GMT Reply-To: davidsen@crdos1.UUCP (bill davidsen) Organization: GE Corp. R & D, Schenectady,NY Lines: 105 Some time ago I posted a question about getting rid of names with / in them, and many people assurred me that it couldn't happen (I had the problem, so it does). Here are some comments on the topic from another group, indicating that other people have this problem, too. I don't intend to start a rehash of the topic, just wanted to share these with people for informational value. ________________________________________________________________ From: jeff@tc.fluke.COM (Jeff Stearns) Newsgroups: comp.protocols.nfs Subject: Yes, Virginia, you *can* have UNIX filenames containing '/' Date: 11 Nov 88 18:50:23 GMT 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. Makes for some fun later when UNIX tries to do anything with the file. As you can imagine, most system calls will fail. This isn't really a bug so much as a consequence of the fact that the NFS spec isn't specific to UNIX semantics. From the NFS point of view, such files should be allowed. It does raise some interesting questions about the limitations of heterogeneous systems. And it's one of the few times when UNIX chokes on a filename which is legal on other operating systems (my example actually comes from a Macintosh speaking to the NFS via a Cayman GatorBox). -- Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064 jeff@tc.fluke.COM {uw-beaver,microsoft,sun}!fluke!jeff PS - Calling all users of the Vitalink TransLAN IV Ethernet bridge! Please drop me a line. ________________________________________________________________ From: guy@auspex.UUCP (Guy Harris) Subject: Re: Yes, Virginia, you *can* have UNIX filenames containing '/' Date: 12 Nov 88 07:09:57 GMT >This isn't really a bug so much as a consequence of the fact that the NFS >spec isn't specific to UNIX semantics. From the NFS point of view, such >files should be allowed. I'd call it a bug in the UNIX NFS server code as distributed by Sun; it's serving up a UNIX file system, and file names (component names) containing "/" are illegal under UNIX. (In fact, I think it *did* call it that, filing a bug report against it....) Since you can't "rm" such files from UNIX, it's kind of impolite of the server to let them through. Such files should be allowed if the server is willing to allow them, but servers aren't obliged to allow them (you could write an NFS server for a file system that allowed only 26 files named "A" through "Z" if you want). ________________________________________________________________ From: arosen@hawk.ulowell.edu (MFHorn) Subject: Re: Yes, Virginia, you *can* have UNIX filenames containing '/' Date: 12 Nov 88 19:26:29 GMT 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 -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me