null length directory: SUMMARY

[Patrik Eschle]

This is a summary of the many responses I received to my article
<1410 at forty2.physik.unizh.ch>.

My Problem was to remove a directory entry with a null length
filename:

>  We have somehow (a PC and NFS were involved) succeeded to create the
>  following directory entries:
>
>     % \ls -aliqF
>     total 3
>        351 drwxrwxrwx  2 eschle       1024 Dec 19 12:57 /
>        347 drwxrwxrwx  2 eschle       1024 Dec 19 12:57 ./
>      57547 drwxr-xr-x 18 eschle       1024 Dec 19 10:48 ../
>
>  The first directory with inode nr. 351 has a filename of length 0.


The only solution (except for accessing the raw disk) is to use
clri(8) to clear the inode 347 (the current directory) and then let
fsck(8) relink the lost blocks and inodes (this should be done
in single user mode or with umounted disks of course).

Some Highlights:

 - Chris Torek <chris at cs.UMD.EDU> pointed out, that fsck should find
   the invalid entry and fix it (does not work here).

 - Root Boy Jim <rbj at uunet.uu.net> explained, that in pathnames like
   '//usr///lib////libc.a' the interpretation of the null length
   filename as current directory '.' makes sense.

 - Glen Eustace <G.Eustace at massey.ac.nz> mentioned, that they had
   have the same problem and that also PCNFS was involved.

 - The proposed 'unlink' of the directory did not work, I got a 'not
   owner' (as root).

 - All methods that need to access the file through it's name do not
   work here (rm -r *, find -inum 351 -exec rmdir {} etc.)

Thanks to everybody who replied

Patrik


-- 
Patrik Eschle, Physics Institute University of  Zuerich (Switzerland)
inet: eschle at physik.unizh.ch (bang: uunet!chx400!forty2!eschle)
                   "sorry, no quote today"
          -> Send CHUUG mail to chuug at chuug.uu.ch <-