trashed directory from system crash

Best of the Newsgroups: trashed directory from system crash

Main Index
Bela's advice is good as usual; the only thing I'd add is to do all of the work in single user mode: the system is already slightly whacked, so why risk someone or something doing something that makes things worse?

Though I think I'd also consider starting over from backup - who knows what other crapola lurks within? Some of this shows up as visible damage, but anything that scrambles directories also could have scrambled files.

From: Bela Lubkin <filbo@armory.com>
Subject: Re: bad directory names
Date: 16 Nov 2005 16:26:28 -0500
Message-ID: <200511161326.aa11337@deepthought.armory.com> 
References: <1132159163.544169.118220@g14g2000cwa.googlegroups.com> 

"dazole" wrote:

> I had a 3.2 5.0.6 server crash pretty hard the other day (power
> outtage, bad UPS...yeah, I know).   I have run into a rather
> interesting problem on recovery, though.  There are many, *many*
> directories that are missing the '.' directory entry.  However, I can
> create the '.' directory with no problem.
> 
> Here's the screwy part.   After creating the '.', and doing an 'ls
> -al', I see the following:
> 
> drwxr-xr-x   2 root     sys          512 Nov 16 06:45 .
> drwxrwxrwx 396 root     root        8192 Nov 15 17:34 ..
> drwxrwxrwx   3 root     root         512 Nov 16 06:45 .;34672
> 
> 
> Some of the directories even have a '..;34672' directory.
> 
> I have been fairly successfull in removing the '..;34672' directories
> (using unlink.  rmdir fails), however, sco wont let me remove the
> single-dot entries.  The OS believe they are the actual '.' directory.
> I can even cd into the directory about 50 times (got bored after that)
> with the results being:
> 
> # pwd
> /full/path/to/parent/directory/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/
> .;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/
> .;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/
> .;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/.;34672/
> .;34672
> 
> 
> If I "mkdir .", then unmount the filesystem and run "fsck -d -ofull -D
> -s filesystem", I get prompted for duplicate '.' directories, which I
> answer yes to fix, but the (in my mind) wrong directory gets removed.
> It removes the '.' directory and not the '.;34672' directory.
> 
> Any tips on how I can get rid of these things other than a complete
> wipe and re-install?

Take Control of Upgrading to Snow Leopard

Take Control of Exploring & Customizing Snow Leopard


You can fix individual directories by recreating them:

  # cd /full/path/to/parent
  # mkdir directory.new
  # mv directory/* directory.new/*

This moves everything that isn't a ".*" file.  In most directories that
will be everything (other than "." ".." and any messed up ".;number"
files).  In some cases you may need to manually move other dot files.
You can do things like:

  # mv directory/.[a-zA-Z0-9]* directory.new

Once you've removed everything useful from the directory, you can
obliterate the bad directory itself.  Don't use `rm -rf`, because it may
misbehave and follow the "..;number" links and wipe out the parent
directory.  I don't _know_ that it would do that, but it isn't worth
risking.

Instead, start with a simple `rmdir directory`.  I expect that will
fail.  Try to remove any unusual links from the directory and do it
again:

Take Control of Switching to the Mac

Take Control of VMware Fusion 3


  # unlink "directory/.;34672"
  # unlink "directory/..;34672"
  # rmdir directory

If you can't get to a point where `rmdir` is willing to do its job, try:

  # unlink directory

and if that still won't go, try `clri`.  You need to collect the inode
number and filesystem device name:

  # ls -lid directory
  94773 drwxrwxrwx   3 root     root         512 Nov 16 06:45 directory
  ^^^^^ inode#

  # df -v directory
  Mount Dir  Filesystem              blocks      used      free   %used
  directory  /dev/u               226194926 100201524 125993402    45%
   ###       ^^^^^^ filesystem device name

  # clri /dev/u      94773
   ###   ^^^^^^^^    ^^^^^
   ### device name   inode # from `ls -lid`
   ###  from `df

Make sure the device name here is correct.  If you give the wrong device
name, you'll destroy some completely unrelated file!

When the old one is completely gone, finish the job by renaming the new
directory into place:

  # mv directory.new directory

Once you've cleaned up all the directories, unmount the filesystem and
fsck it:

  # fsck -o full /dev/u

If it's the root filesystem, reboot, go to single-user mode, and:

  # fsck -o full /dev/root

Good luck...

>Bela<

Comments /Bofcusm/2634.html

Add your comments