Unix tip: Rescuing files from lost+found

The lost+found directory included in (Unix) file systems is usually empty. Only used when fsck doesn't know what to do with files that have lost their place in the file system, they stand as a temporary holding place for those rare instances in which fsck can't put everything back together after file systems have become corrupt in some way. If you see files in lost+found, you can expect them to look rather unusual. Take these files found on a Solaris 9 system after a panic and a subsequent fsck:

  -rw-r--r-- 1 johndoe staff 1576 Apr 22 11:26 #00805349
  -rw-r--r-- 1 johndoe staff 4363 Apr 22 11:26 #00805350
  -rw-r--r-- 1 johndoe staff 4566 Apr 22 11:26 #00805351

The names of these files were lost before fsck tried to piece things back together. The directory that had originally contained the salvaged files was, for some reason, not recoverable. And, since filenames are stored in directory files and nowhere else on ufs file systems, what we are able to recover for these files are the various pieces of information stored in the files' inodes -- the owners, groups, access permissions and pointers to the files' contents.

To examine one of these files, put quotes around the current names. These represent the inode numbers. For example, #00805349 is the file associated with inode 805349. The command shown below will page through the file contents as would more on any normal file:

  # more "#00805349"

You might also find directories in lost+found. In this case, the parent directories of those directories will also have been lost

  drwxr-xr-x 2 johndoe staff 512 Apr 21 10:26 #00804845
  drwxr-xr-x 2 johndoe staff 512 Apr 21 10:46 #00804854
  drwxr-xr-x 2 johndoe staff 512 Apr 21 10:46 #00804866
  drwxr-xr-x 2 johndoe staff 28160 Apr 22 10:45 #01514211
  drwxr-xr-x 2 johndoe staff 28160 Apr 22 10:48 #01514212
  drwxr-xr-x 2 johndoe staff 30208 Apr 22 11:26 #02383477

If you use a cd command such as this to move into one of these directories, you are not going to see any files:

  # cd "#02383477"
  # ls
  #

While these directories may appear to be empty, however, this is only partly true. The files that once occupied these directories may be among the files now represented only by their inodes. On the other hand, the filenames will still be contained in the directory files and you can extract them if this information is of any value. With no connection to the lost files, I have found directory files in lost+found to be of little value. The revelation that some unknown directory used to contain a file named "install.sh" is not likely to be of significant help in putting the lost files back in place. In the lost+found directory files that I examined, the inode numbers are generally gone and only the scattered file names are easily retrieved. The directory dump shown below, for example, shows that the now detached directory once contained four files -- root-of-node, build-in-progress, bin and hdr.

  bash-2.05# od -xc "#00804845"
  0000000 000f e6cf 000c 0001 2e00 0000 0000 0003
  \0 017 a I \0 \f \0 001 . \0 \0 \0 \0 \0 \0 003
  0000020 01f4 0002 2e2e 0000 0000 0000 000c 0002
  001 o \0 002 . . \0 \0 \0 \0 \0 \0 \0 \f \0 002
  0000040 6363 0000 0000 0000 0034 000c 726f 6f74
  c c \0 \0 \0 \0 \0 \0 \0 4 \0 \f r o o t
  0000060 2d6f 662d 6e6f 6465 0000 0000 0000 0000
  - o f - n o d e \0 \0 \0 \0 \0 \0 \0 \0
  0000100 001c 0011 6275 696c 642d 696e 2d70 726f
  \0 034 \0 021 b u i l d - i n - p r o
  0000120 6772 6573 7300 0000 0000 0000 000c 0003
  g r e s s \0 \0 \0 \0 \0 \0 \0 \0 \f \0 003
  0000140 6269 6e00 0000 0000 019c 0003 6864 7200
  b i n \0 \0 \0 \0 \0 001 234 \0 003 h d r \0
  0000160 0000 0000 0000 0000 0000 0000 0000 0000
  \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
  *
  0001000

Moving the files back to their proper places in the OS and renaming them is largely an exercise in recognizing them and issuing the proper mkdir and mv commands to rebuild the contexts in which they previously resided. This can be easy or next to impossible depending on how many files have been dislodged and dumped into lost+found and how recognizable they are. In general, it is probably far less work to pull files from backup than it is to resurrect them from their lost+found orphanages. The prime factor is probably whether it's easier to notice what's been lost from your directories or to identify what's been found and saved in lost+found.

Unix commands such as the file and strings commands can be somewhat helpful in identifying file contents. The file command might tell you that some of the files are scripts or binaries. Strings might help you to recognize binary files.

If you recognize a file in lost+found and want to put it back where it belongs, you can use the mv command with the "inode style" filename in quotes:

  # mv "#00805350" /export/home/johndoe/program.c

You can also easily remove files or directories from lost+found:

  # rmdir "#00804845"

Fortunately, fsck is generally able to repair most system damage and the frequency with which you will find anything at all in your lost+found directories has slowed significantly. It's good to know what to expect, remember to check lost+found after messy crashes and be ready to respond if you find some files needing new -- or should I say "old" -- homes.