unlink(inode)? or how to remove file with '/' in its name

[Chris Torek]

>In article <1990Oct20.182146.27039 at isis.cs.du.edu> cbrandau at 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 at virtech.uucp> cpcahil at 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 at cs.umd.edu	Path:	uunet!mimsy!chris