eschle@forty2.physik.unizh.ch (Patrik Eschle) (12/21/90)
This is a summary of the many responses I received to my article <1410@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@cs.UMD.EDU> pointed out, that fsck should find the invalid entry and fix it (does not work here). - Root Boy Jim <rbj@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@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@physik.unizh.ch (bang: uunet!chx400!forty2!eschle) "sorry, no quote today" -> Send CHUUG mail to chuug@chuug.uu.ch <-