FFSRECOV(1)               BSD General Commands Manual              FFSRECOV(1)

     ffsrecov — aid to recover files from corrupt ffs filesystems

     ffsrecov [-adps] [-c inum -n name | -f inum | -i inum] [-r name] file

     The program ffsrecov is used to aid in the recovery of file data from a
     corrupt file system.

     The options are as follows:

     -a          Dump all files on the filesystem that have the mode IFREG in
                 the inode.  They will be put into the local directory with
                 their name being the inode number the data came from.

     -c inum -n name
                 Recreate inum in the current directory with the name name.
                 If inum is a directory, it will create the directory, and
                 populate it with it's children.

     -d          Dump all the inodes with the mode IFDIR.  The listing will
                 contain each file name and inode number that goes with the
                 file.  Each directory is listed on a single line.

     -f inum     Print out inode information for inum.

     -i inum     Dump out the data belonging to inum to stdout.  It will write
                 out blank blocks as you can't seek on stdout

     -p          Print out the information contained in the superblock.

     -r name     Prints out the inode and the parent inode of any file that
                 matches name.

     -s          Find possible superblocks in the filesystem.

     file        Operate on the file system file.  This requires that you can
                 both mmap(2) and fstat(2) the file to obtain the size of it.

     The following is an example of a typical usage of the ffsrecov command:

           % ffsrecov -p ffs.image

     If you would like to recover inode 2385 named dir and all it's decendants
     the command:

           % ffsrecov -c 2385 -n dir ffs.image

     will create dir, populate it, setting modes and permissions to the

     This manual page was written by John-Mark Gurney <jmg@FreeBSD.org>.

     The code doesn't handle triple indirect blocks.  This shouldn't be a
     problem due to the fact that on a standard 4096/512 system, you can
     represent a 2**32 byte file without triple indirect blocks.

                                 April 8, 1999