Hi Friends,

How can I Restore the Files present under "lost+found" Directory of a FileSystem (in Solaris & Tru64 OS) to their original Locations.

[I know that files that go deferenced from the Filesystem in the aspect of INODES/BLOCK/etc get updated in the lost+found Directory of that FileSystem, when booting the system or manually doing FSCK on that FileSystem]

Now-a-days I am loosing lots of files in 2 of my Machines,
One running Solaris8 and other Tru64(Digital) Unix.

Thanx in Advance.....

FYI - if you are losing files consistantly, then you may have bigger problems than worring about cleaning up lost+found. Check your /var/adm/message file and dmesg for errors on the drive(s).

Fix for Solaris:

Orphaned files and directories (allocated but not referenced) are placed
in lost+found during "fsck" operations. Files are named by the inode
reference "as found" by fsck. Files present in this directory are
inconsistent or badly injured.
Solution Summary Top

The File System Debugger (fsdb) utility is a straightforward although
not the most user friendly allowing the repair of file systems at a much
lower level than fsck. Great care must be taken when using fsdb,
absolute changes are being made to bowels of the file system.

A file "/lost+found/4224" at inode 3708 in the root file system will be
used in all examples. The inode of lost+found is 366.

Fsdb runs in two modes, interactive and command file. Both modes are
used. A command file with:

3708i
3708i.fd
q

The first line lists the inode data and the second lists the directory
entries. "q" indicates quit. Using this file makes it easier to
observe data as it will scroll by quickly in interactive mode.

Several data gathering steps should be followed prepartory to any
repairs.

1) "ls" command, "ls -ai 4224", and ls -i.
2) fsdb /dev/root <cmd >/tmp/out.tmp

Example 1:

"ls data"
ls -i
3807 4224
ls -ia 4224
366 .
3807 (

"out.tmp" file contents.

/dev/root(root): 1k byte Block File System
FSIZE = 65710, ISIZE = 16416
i#: 3807 md: d---rwxr-xr-x ln: 2 uid: 0 gid: 0 sz: 48
a0: 58951 a1: 0 a2: 0 a3: 0 a4: 0 a5: 0 a6: 0
a7: 0 a8: 0 a9: 0 a10: 0 a11: 0 a12: 0
at: Sat Jul 1 10:31:36 1995
mt: Mon Jul 3 11:26:16 1995
ct: Sat Jul 1 10:26:16 1995
d0: 366 .
d1: 2660 (
d2: 0
(out truncated)
d63: 0

The back reference entry (parent directory) was inode 2660. Main
problems are the back reference to the parent and the ".." entry.

To repair the directory the file and delete it

The steps to perform the task are:

1) Fix up the inode number by entering:
3807i.a0b.d1=3807
2) Fix dot-dot directory reference entry
d1.nm=".."
3) Enter q to quit.

4) Verify the directory entry by use of the fsdb cmd file sequence.

5) Use the "rmdir" command to remove the directory.

Example 1:

"ls data"
ls -i
3807 4224
ls -ia 4224
0 .
4967 (

"out.tmp" file contents.

/dev/root(root): 1k byte Block File System
FSIZE = 65710, ISIZE = 16416
i#: 3807 md: d---rwxr-xr-x ln: 2 uid: 0 gid: 0 sz: 48
a0: 58951 a1: 0 a2: 0 a3: 0 a4: 0 a5: 0 a6: 0
a7: 0 a8: 0 a9: 0 a10: 0 a11: 0 a12: 0
at: Sat Jul 1 10:31:36 1995
mt: Mon Jul 3 11:26:16 1995
ct: Sat Jul 1 10:26:16 1995
d0: 0 .
d1: 2660 (
d2: 0
d3: 3450 d a t a f i l e . d a t
(several other names)
(out truncated)
d63: 0

The back reference entry (parent directory) was inode 2660. Main
problems are the back reference to the parent, the self reference "."
and the ".." entry. There are many valuable data files here which
should be retained.

To repair the directory the file and delete it

The steps to perform the task are:

1) Fix up directory slot 1 inode number by entering:
3807i.a0b.d1=3807
2) Fix dot-dot directory reference entry
d1.nm=".."
3) Fix up directory slot 0 inode number by entering:
3807i.a0b.d0=3807
4) Fix dot directory reference entry
d0.nm="."
5) Enter q to quit.

6) Verify the directory entry by use of the fsdb cmd file sequence.

7) rename 2442 to a more significant name and back it up to a safe
location using a command similar to "tar -cvf safeplace name".

8) Use the "rmdir" command to remove the directory.