Path: utzoo!attcan!uunet!wuarchive!udel!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: unlink(inode)? or how to remove file with '/' in its name
Message-ID: <27087@mimsy.umd.edu>
Date: 21 Oct 90 06:24:22 GMT
References: <1990Oct18.030832.10894@melb.bull.oz.au> <1990Oct21.002523.27266@virtech.uucp>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 52

>In article <1990Oct20.182146.27039@isis.cs.du.edu> cbrandau@isis.UUCP
>(carl brandauer) writes:
>>First, why write a C program when 'ls -i' will return the inumber (NOT inode)
>>of the file.

(This depends on your `ls'.  The inode number is available in the directory
entry, but the last person to hack on `ls' may not not have been clever enough
to avoid an extra stat() call.)

>>	find . -inum nnn -exec rm {} \;
>>will do what you need.

In article <1990Oct21.002523.27266@virtech.uucp> cpcahil@virtech.uucp
(Conor P. Cahill) writes:
>No it won't.

Right.

>The problem with a filename that has a '/' in it is that
>there is no way to access that file because the low level kernel 
>routines interpret the '/' as a directory separator.

Confusing.

It is the *high level* KERNEL routines that interpret slashes.  The
problem is that NFS sits below this level.  Pictorially:

		[user space]
 -------|-------------------------------------------
 	|	[kernel space]
	|
  +-----v-----+
  | look for  | system calls
  | '/' and 0 | (open, link, unlink, stat, rename, ...)
  +-----v-----+
	|
	|
  +-----v-----+
  | r/w file  |
  | names in  <------------- NFS
  | directory |
  +-----v-----+
  	|
   (disk I/O)

Since NFS bypasses the code that makes sure each directory component
is valid, it is entirely capable of creating (and removing) invalid
component names.  (The same is true of disk I/O errors and bugs, which
is why fsck should check for such names.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris