c91a1-rd@amazon.Berkeley.EDU (Raja (Reader)) (02/23/90)
Hello. I happen to run a small workstation cluster hereabouts, and recently encountered a rather annoying, though not really threatening problem. I tried to remove an old, unwanted directory in the root system. There werea couple of subdirectories in that directory, and no matter what commands I used, I just could not remove it. rm -R, rmdir, etc. I then ran icheck and then fsck, and still no errors were reported. Then, on doing an ls -ilR, I noted that the directories were circularly linked! One of the subdirectories had the same inode number as it's parent. I then ran clri, and tried to first remove that inode number only, and then that inode nbr and the other sub-directory inode. Both times I failed. I don't know what I can do now - clri has failed! Short of restoring the tape-backup from a month ago, I can't think of anything else. Any ideas, gentlemen? Raja S Kushalnagar. (Programmer Analyst I, S & P Dept, UC Berkeley) Disclaimer: I am only a poor foriegn undergrad sophomore who just turned 18 a half a year ago; if anything serious happens, I plead juvenile delinquency!
bob@pds3 (Robert A. Earl) (02/25/90)
In article <22347@pasteur.Berkeley.EDU> c91a1-rd@amazon.Berkeley.EDU.UUCP (Raja (Reader)) writes: >I tried to remove an old, unwanted directory in the root system. >There werea couple of subdirectories in that directory, and no matter what >commands I used, I just could not remove it. rm -R, rmdir, etc. I then ran >icheck and then fsck, and still no errors were reported. Then, on >doing an ls -ilR, I noted that the directories were circularly linked! >One of the subdirectories had the same inode number as it's parent. >I then ran clri, and tried to first remove that inode number only, and >then that inode nbr and the other sub-directory inode. Both times I failed. If you have root permissions on your system, you should be able to use the 'unlink' command to solve this one. (Note: I have just created and solved the problem you described on my SCO XENIX 386 2.3.2 system, SVR2 + BSD stuff) Here is what I would do: (assume /tmp/junk is the dir to be deleted, /tmp/junk/oops is the recursion) login as root. cd /tmp/junk ls -lia (which produces: total 8 4302 drwxr-xr-x 3 bob pds 48 Feb 24 13:29 . 19 drwxrwxrwx 3 bin bin 1616 Feb 24 13:29 .. 4302 drwxr-xr-x 3 bob pds 48 Feb 24 13:29 oops ) unlink oops ls -lia (which now gives: total 6 4302 drwxr-xr-x 2 bob pds 48 Feb 24 13:30 . 19 drwxrwxrwx 3 bin bin 1616 Feb 24 13:30 .. ) cd rmdir /tmp/junk Hope this helps! -- ============== Robert A. Earl uunet!pds3!bob
mikel@teda.UUCP (Mikel Lechner) (02/27/90)
bob@pds3 (Robert A. Earl) writes: >In article <22347@pasteur.Berkeley.EDU> c91a1-rd@amazon.Berkeley.EDU.UUCP (Raja (Reader)) writes: >>I tried to remove an old, unwanted directory in the root system. >>There werea couple of subdirectories in that directory, and no matter what >>commands I used, I just could not remove it. rm -R, rmdir, etc. I then ran >>icheck and then fsck, and still no errors were reported. Then, on >>doing an ls -ilR, I noted that the directories were circularly linked! >>One of the subdirectories had the same inode number as it's parent. >>I then ran clri, and tried to first remove that inode number only, and >>then that inode nbr and the other sub-directory inode. Both times I failed. >If you have root permissions on your system, you should be able to use the >'unlink' command to solve this one. (Note: I have just created and solved the >problem you described on my SCO XENIX 386 2.3.2 system, SVR2 + BSD stuff) I once this problem in an old release of SunOS (3.2 I think). The unlink command refused to delete a directory which was linked. It turned out that the system call to remove a directory tested for a link count == 2 before attempting to delete the directory. This was used as a shortcut to avoid checking the directory to determine if it was really empty. However, in the case of a linked directory the link count for an emtpy directory is > 2. I deleted the problem directory by: 1) bringing the system to single user, 2) sync'ing the disks, 3) clri'ing the offending inode, 4) stopping the system and rebooting with a sync, 5) running fsck on reboot which finds and fixes the filesystem errors, caused by the clri. -- If you explain so clearly that nobody can misunderstand, somebody will. Mikel Lechner Teradyne EDA, Inc. UUCP: mikel@teraida.UUCP