directory that cannot be deleted due to inode 1

[mcpn]

Had a system crash the other day which fsck kindly fixed for me (or so I thought).

What started it was an unrecoverable write error. We decided to shutdown and run an fsck. This found a read error and offered to salvage it. The messages was
cannot read block 641322, i=41219 owner=bin, mode=40755, size 512, dir ? salvage y/n. We said yes and then got the following:-
missing '.' i=41219 node=40755 size=512 dir=/udk/usr/lib/locale/fr_FR.850/LC_MESSAGES fix y/n. We said yes. We then got:-
writing zeroed block 641322 to disk.

fsck then continues okay and we assumed that all was fixed. However, I find that we now have a directory which has a directory within it with the same inode! This is /udk/usr/lib/locale/fr_FR.850/LC_MESSAGES its inode is 41219 and within it there are two directories ..;28860 with inode 41218 and .;28860 with inode 41219! I believe these are spurious entries.

This causes problems with our full system backup (it loops around) Other scripts that scan the file system stop working once these get into this directory.

So anybody have an idea on how to fix this? We cannot delete it or fix it with fsck (I've tried -s -ofull -D).

Any suggestions would be appreciated. I've already had the reload SCO suggestion!

Mike

 

[tabert]

I have a similar problem. I have files names in a directory that can't be deleted. When find runs on the nigthly backup, I get "find: cannot acess /usr/edi/data/set_out/07201500.04: No such
file or directory (error 2)".

I can't delete. As in your case, fsck has not fixed it. As a work around (to get the files out of the working directory, I moved the directory to a new name, set_out.corrupt. Then recreated the original directory and moved the files (the real ones) from set_out.corrupt to the new set_out.

I still have the errors during backup, but the working directory seems healthy. I'll run it this way until I can find a complete solution to the problem.

Larry

 

[stanhubble]

Have you tried to delete the directory fr_FR.850 ?

rm -r fr_FR.850 from the the /udk/usr/lib/locale directory.
if it works then you may want to rerun fsck.

be careful with rm -r


HTH
stan

 

[mcpn]

thanks to talbert and stanhubble for their suggestions.

stan, the rm -r won't work as one of the files inside the directory has the same inode as the directory itself and it just doesn't like it.

tabbert, it looks like you have a similar problem and you will be please that I have a solution.

I fixed this problem using a utility called 'clri' which allows you to clear an inode. SCO's technical arcticle TA105169 has some useful information on what to do. I used it to remove the directory completely in single user mode then used fsck to repair the file system and reattach the files I wanted to keep.

Mike