Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!aimt!breck
From: breck@aimt.UUCP (Robert Breckinridge Beatie)
Newsgroups: comp.unix.wizards
Subject: Re: help with missing lost+found!
Message-ID: <65@aimt.UUCP>
Date: Fri, 21-Aug-87 00:07:10 EDT
Article-I.D.: aimt.65
Posted: Fri Aug 21 00:07:10 1987
Date-Received: Sat, 22-Aug-87 16:12:12 EDT
References: <180@LOGICON.LOGICON.UUCP> <142700014@tiger.UUCP> <330@sering.cwi.nl>
Organization: AIM Technology, Palo Alto, CA
Lines: 77
Summary: no such animal as mklost+found in tfm

In article <330@sering.cwi.nl>, fmr@cwi.nl (Frank Rahmani) writes:
> In article <142700014@tiger.UUCP>, rjd@tiger.UUCP writes:
> > > (BESIDES running mkfs) to recreate an accidentally deleted lost+found
> >    Why not?  Mkdir() works on my machine....   What kind of machine are
> > you on?
> So what's wrong with
> mklost+found(8)??
> Rtfm!

What kind of system are we dealing with here?  If it's a BSD system, then
mklost+found(8) will work.  If it's a 4.3 BSD system, then as rick@seismo
has already pointed out, fsck will create it's own lost+found directory.
(By the way, I hope I got my references right there.  If not I apologize to
whoever actually pointed out the improved features of fsck in 4.3 BSD)

On the other hand, if it's a System V system, then I'm not so sure that there
is a mklost+found command.  I looked through the indices of volumes 1,2, 3 of
the SVID for a reference to mklost+found and couldn't find any reference to the
command.

At any rate, here's how I would go about it if I had to create a lost+found
directory right now:

First a short C program:

#include <sys/types.h>
#include <sys/dir.h>
#include <sys/stat.h>

struct direct bigbuf[640];

main()
{
    struct stat stbuf;

    if(fstat(1,&stbuf) < 0)  {
	perror("1");
	exit(1);
    }
    strcpy(bigbuf[0].d_name,".");
    bigbuf[0].d_ino = stbuf.st_ino;
    strcpy(bigbuf[1].d_name,"..");
    bigbuf[1].d_ino = 2;
    write(1,bigbuf,sizeof bigbuf);
}

Compile the program and run it redirecting it's output to lost+found (in the
root directory for the file system in question).

Next find the file's inode number.  (ls -i)  Now, and this might not be totally
necessary, but it's better safe than sorry, unmount the file system in question.

Now run fsdb on the file system.  Then tell fsdb, "<i-num>i.md=16895" where
<i-num> is the inode number of the lost+found file you just created.  Note
the number 16895 should turn the file into a directory that has permissions:
drwxrwxrwx.  Next you have to increment the link count for the new directory
(it now has a link to itself).  Tell fsdb, "<i-num>i.ln=+1".  Finally, you
have to update the link count for the root directory of the file system in
question.  Tell fsdb, "2i.ln=+1"

NOTE: The number 16895 might (concievably, not probably) be wrong for your
system.  Check your own system.  Create a real directory with mkdir and make
it readable, writable, and searchable by everyone.  Then use fsdb to find
the actual value in the mode field for it's inode.

Finally, just to make sure that the file system is healthy, run fsck on the
file system.  Hopefully, it will pass.

Disclaimer: No I haven't tried doing this.  Not for a couple years anyway.
Also, I can't guarantee that this will work.  Nor can the company I work for.
Don't do this if you can't afford to corrupt your file system.  Don't do this
if you want to sue me or the company I work for.  I'm not kidding.  I think it
will work, but I can't be held responsible for any damage resulting from use
of this technique.
-- 
Breck Beatie
uunet!aimt!breck