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

[Chris Torek]

In article <1990Oct18.030832.10894 at melb.bull.oz.au>
sjg at sun0.melb.bull.oz.au (Simon J. Gerraty) writes:
>...using an Appletalk-NFS gateway ... one of our users created a
>file on one of our Sun's with a '/' in the name.  Unfortunately he
>forgot to remove the file before returning the gateway. ...
>So, have I missed something, or do I have to resort to editing
>the raw disk file?  

Step 0 (apply iff necessary): fix fsck (and/or install the 4.3BSD-reno
fsck).  This requires sources, unfortunately.  Fortunately, the vendor
has sources.  Unfortunately, the vendor tends to be uncooperative in
this sort of situation.

Step 1: move all the good files out of the directory (this is to make step 2
simpler).

Step 2: run fsck.  It will say

	... DIRECTORY CORRUPTED.  FIX?

Answer yes.  It will then eventually want to reconnect or clear the file
it lost when it `fixed' the directory.

Alternatively, you can clri the inode of the directory, and all files
within that directory that have no other links will be recovered into
lost+found (again, moving all the other files helps here).

>I would also be interested to here how NFS created the stupid
>file in the first place.  Perhaps I can write an programme to
>ask NFS to remove it?

Yes, you can, though it is nontrivial.  The trick is that NFS does
not have `path names'; it just has `names'.  To look up /foo/bar/baz
you get a `file handle' on / and look up foo.  This gives a new file
handle, and you look up bar; this gives yet another file handle you
can use to look up baz.  For whatever silly reason, the Sun NFS
server code does not check for `impossible' characters in each file
lookup or create operation.  So it is possible to get an NFS handle
for the parent directory and hand the kernel a `remove' request with
the `file name', even though it does have an embedded slash.
-- 
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