sloane@LOGICON.LOGICON.UUCP (Gary Sloane x251) (08/04/87)
Do any of you wizards out there in netland have a quick and easy way
(BESIDES running mkfs) to recreate an accidentally deleted lost+found
directory? Using mkdir() doesn't cut it...
Gary Sloane
LOGICON T&TSD
San Diego
(619) 455-1330
Please respond via mail to ...!nosc!logicon!sloaneroy@phri.UUCP (Roy Smith) (08/11/87)
In <180@LOGICON.LOGICON.UUCP> sloane@LOGICON.LOGICON.UUCP (Gary Sloane x251)
Wants to know how to recreate a missing lost+found directory but says:
> Using mkdir() doesn't cut it...
Why not? Doing:
cd <root of your file system>
mkdir lost+found
cd lost+found
for i in `series 1 100`; do touch $i; done
rm *
should do the trick and I can't imagine anything much more straight-forward.
Of course, if you don't have Gary Perlman's "series" program, you have to
think of some other way to generate a list of numbers, or type them by hand.
The file names are unimportant; "for i in `ls /tmp`" should work fine if
you have lots of /tmp files.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016rjd@tiger.UUCP (08/11/87)
> Do any of you wizards out there in netland have a quick and easy way > (BESIDES running mkfs) to recreate an accidentally deleted lost+found > directory? Using mkdir() doesn't cut it... Why not? Mkdir() works on my machine.... What kind of machine are you on? Randy
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (08/12/87)
In article <2836@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >> Using mkdir() doesn't cut it... > >Why not? Doing: > > cd <root of your file system> > mkdir lost+found > cd lost+found > for i in `series 1 100`; do touch $i; done > rm * > I vaguely know what the lost+found directory does for a disk partition. Can someone explain the reason for needing 100 empty files in the directory? What happens if you just do mkdir <partition>/lost+found and leave it at that? -- Niels.
kurt@hi.UUCP (Kurt Zeilenga) (08/13/87)
In article <142700014@tiger.UUCP> rjd@tiger.UUCP writes: >> Do any of you wizards out there in netland have a quick and easy way >> (BESIDES running mkfs) to recreate an accidentally deleted lost+found >> directory? Using mkdir() doesn't cut it... >Why not? Mkdir() works on my machine.... What kind of machine are >you on? > Randy (I assume we are talking about 4.X BSD Unix) Well, you should also "grow" the directory size so fsck has plenty of empty slots to put orphaned files and directories in after mkdir lost+found in the root of the filesystem. An easy way to do this is to create many empty files in the directory and then delete them all.
michael@macom1.UUCP (Michael Mullins) (08/14/87)
in article <142700014@tiger.UUCP>, rjd@tiger.UUCP says: > Nf-ID: #R:LOGICON.LOGICON.UUCP:-18000:tiger.UUCP:142700014:000:277 > Nf-From: tiger.UUCP!rjd Aug 11 09:03:00 1987 > > > >> Do any of you wizards out there in netland have a quick and easy way >> (BESIDES running mkfs) to recreate an accidentally deleted lost+found >> directory? Using mkdir() doesn't cut it... > > Why not? Mkdir() works on my machine.... What kind of machine are > you on? Wrong! Just making a new lost+found directory is not sufficient. The typical procedure is to mkdir lost+found and then use some kind of script to make about 2000 NULL files, then remove them. This provides enough entries in the directory database to link a whole bunch of lost files to that directory when fsck finds them. If fsck discovers 500 unreferenced files, and the maximum number of files that had ever been created at one time was 10, guess what? You just lost 490 files forever! Maybe some of you Guru's out there could map out the disk and trace every single sector by hand, but that will take more time than I can possibly spend on something like that, and you will still loose data if UN*X has marked these blocks as avail. and some other file decides to use the space. -- John Michael Mullins CENTEL Business Information Systems, Inc. 5515 Security Lane, Rockville, Maryland, 20852, (301) 984-3636 UUCP: michael@macom1.UUCP or decuac!macom9@tly (the
rick@seismo.CSS.GOV (Rick Adams) (08/14/87)
Actually, what should happen is that whoever you got your system from should FIX their fsck. The 4.3 BSD fsck will create a lost+found if neceessary (and do some other really nice things). If you have a 4.2 BSD based file system it should be trivial to port the 4.3bsd fsck. If you don't, you can still steal most of the code. There is no excuse for still requiring a lost+found directory. (For a good time do a clri 2 on your 4.3 BSD root filesystem. Then be highly impressed when fsck says "ROOT INODE UNALLOCATED. ALLOCATE?" For a really good time, do the clri on a friends terminal who doesn't know that the 4.3bsd fsck can recover that. The facial expression can be priceless) ---rick
dave@murphy.UUCP (Dave Cornutt) (08/14/87)
In article <142700014@tiger.UUCP>, authorplaceholder@tiger.UUCP.UUCP writes: > > > > Do any of you wizards out there in netland have a quick and easy way > > (BESIDES running mkfs) to recreate an accidentally deleted lost+found > > directory? Using mkdir() doesn't cut it... > > Why not? Mkdir() works on my machine.... What kind of machine are > you on? Mkdir by itself isn't sufficient. Several people have posted shell scripts that make a directory, create a bunch of files in it, and then delete the files. This works, at least for BSD4.2, and I think SYSV too. The idea is to create a bunch of directory slots and force the directory to be extended; this is necessary because fsck is not capable of extending the directory (after all, you can't expect the entire file system to be implemented inside fsck). If fsck tries to move some lost files to the lost+found directory, and there is no space left in the directory, you're out of luck. Now, here's my question: I've seen several postings here saying that BSD4.3 is capable of shrinking directories. In that case, if I create a bunch of files in a lost+found directory and then delete them, what's to stop it from shrinking the directory and undoing the effect? --- "I dare you to play this record" -- Ebn-Ozn Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL [Ignore header, mail to these addresses] UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt ARPA: dcornutt@gswd-vms.arpa "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."
aegl@root44.UUCP (08/15/87)
In our fsck (MtXinu 4.3 bsd - perhaps in ordinary 4.3 too) there is code to make a lost+found directory if it does not exist - and to grow it if it runs out of free slots. I've never tried deliberately removing a lost+found directory and corrupting a file system to see if it works though. Tony Luck
guy@gorodish.UUCP (08/16/87)
> Several people have posted shell scripts that make a directory, create a > bunch of files in it, and then delete the files. This works, at least for > BSD4.2, and I think SYSV too. The idea is to create a bunch of directory > slots and force the directory to be extended; this is necessary because fsck > is not capable of extending the directory (after all, you can't expect the > entire file system to be implemented inside fsck). This does work in 4.2 and S5. However... > Now, here's my question: I've seen several postings here saying that BSD4.3 > is capable of shrinking directories. In that case, if I create a bunch > of files in a lost+found directory and then delete them, what's to stop > it from shrinking the directory and undoing the effect? Nothing - but then it shouldn't matter in most cases, since the 4.3BSD "fsck" *is* capable of extending (or creating!) "lost+found" in most cases. (It looks like it won't do it if 1) it will require the directory's file map to have an indirect block, or if the directory's file map already has an indirect block - but then with a 4K/x file system, and 512-byte disk blocks, that won't happen until "lost+found" is 5120 bytes long, or 10240 bytes long with an 8K/x file system; 2) it can't allocate a block, e.g. because the file system is full.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
rjd@tiger.UUCP (08/17/87)
> >> Do any of you wizards out there in netland have a quick and easy way > >> (BESIDES running mkfs) to recreate an accidentally deleted lost+found > >> directory? Using mkdir() doesn't cut it... > > > > Why not? Mkdir() works on my machine.... What kind of machine are > > you on? > > Wrong! Are you sure I am wrong? At least for Unix system V on the AT&T 3B2, 3B5, 3B15 computers, the ones I have most experience with, all that needs to be there is the directory. I have lost BIG files and have them reappear properly after having "rm -r lost+found ; mkdir lost+found" it to get rid of trash. I have lost /usr/terminfo once, and it reappeared in /usr/lost+found.... Like I said: which machine/operating system are you on?? I do not believe that the creation of millions of files is need on all op systems. Randy
kyle@xanth.UUCP (08/18/87)
In article <142700015@tiger.UUCP>, rjd@tiger.UUCP writes: > Are you sure I am wrong? > .... I have lost BIG files and have them reappear properly The size of the lost files isn't the salient point here, the NUMBER of lost files is. The point of creating a lot of files in lost+found and deleting them is to create enough enough empty directory slots so that fsck doesn't run out of them when it is relinking the lost files.
jlw@mtuxo.UUCP (08/19/87)
In article <142700015@tiger.UUCP>, authorplaceholder@tiger.UUCP.UUCP writes: > > > >> Do any of you wizards out there in netland have a quick and easy way > > >> (BESIDES running mkfs) to recreate an accidentally deleted lost+found > > >> directory? Using mkdir() doesn't cut it... > > > > > > Why not? Mkdir() works on my machine.... What kind of machine are > > > you on? > > > > Wrong! > > Are you sure I am wrong? At least for Unix system V on the AT&T 3B2, 3B5, > 3B15 computers, the ones I have most experience with, all that needs to be > there is the directory. I have lost BIG files and have them reappear properly > after having "rm -r lost+found ; mkdir lost+found" it to get rid of trash. Note that no blocks were allocated from the file system to create one file. In fact any fsck should be able to save in lost+found up to 30 files since mkdir automatically creates the . and .. entries. This allocates the entire first block of the directory and thus the addition of a small number of file names/inumbers to the directory doesn't make it overflow into the next block. Joe Wood lznv!jlw a b c d e f g h
fmr@cwi.nl (Frank Rahmani) (08/19/87)
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! -- It is better never to have been born. But who among us has such luck?
michael@macom1.UUCP (Michael Mullins) (08/19/87)
in article <44059@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) says: > > Actually, what should happen is that whoever you got your system from > should FIX their fsck. The 4.3 BSD fsck will create a lost+found if > neceessary (and do some other really nice things). If you have a 4.2 BSD > Sorry Rick, I don't quite agree with that. I am not questioning the fact about the fsck function under BSD, but I don't think I want fsck creating new directory entries in a filesystem that has questionable integrity(sp?). If I have a possible hard error on the drive that is causing the problems in the first place, how much intellegence must fsck have in order to avoid that, and other problems when allocationg new blocks to the lost+found? -- John Michael Mullins CENTEL Business Information Systems, Inc. 5515 Security Lane, Rockville, Maryland, 20852, (301) 984-3636 UUCP: michael@macom1.UUCP or decuac!macom1!michael
jc@minya.UUCP (John Chambers) (08/21/87)
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! Well, I checked again, and sure enough, tfm on this machine doesn't have an entry for mklost+found, in (8) or anywhere else. Furthermore, find(1) can find only one thing by that name: /usr/jc/sh/mklost+found, and I wrote that one myself a couple months back when I discovered that there wasn't one in the system. Before you go insulting people's intelligence, maybe you should think that not all of them are running on the same release as you, and they just might not have all the tools in your library. If anyone wants a copy, I'd be glad to send it to them. But it's more fun to write it yourself. If you are a shell wizard, you'll just type it in and not have much fun; if you are less experienced, it is a good learning experience. BTW, I wonder if my script would work on a Berserkeley system? -- John Chambers <{adelie,ima,maynard}!minya!{jc,root}> (617/484-6393)
breck@aimt.UUCP (Robert Breckinridge Beatie) (08/21/87)
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
breck@aimt.UUCP (Robert Breckinridge Beatie) (08/21/87)
In article <252@macom1.UUCP>, michael@macom1.UUCP (Michael Mullins) writes: > in article <44059@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) says: > > > > The 4.3 BSD fsck will create a lost+found if > > neceessary (and do some other really nice things). > > > > If I have a possible hard error on the drive that is causing > the problems in the first place, how much intellegence must fsck have > in order to avoid that, and other problems when allocationg new blocks > to the lost+found? I'm not sure, since I don't have access to the source for fsck or to a 4.3 BSD system, but it seems that it wouldn't take that much intelligence. Shouldn't it be possible to move the "Check Pathnames" and "Check Connectivity" phases to the end of the list of phases. That is, make sure that all blocks in the free list are actually free and all blocks referenced by inodes are referenced by only one inode. Then any blocks fsck has to allocate to the lost+found directory are guaranteed to be free. As for hard errors on blocks that fsck attempts to allocate for lost+found... Well, it's a problem. But shouldn't such blocks already be out of the way? On at least one system V implementation (I don't know about BSD) bad blocks are linked to inode #1. One possible way to work around this would be for fsck to attempt to read the block that it attempts to allocate for lost+found. If the block is bad, then wouldn't the read fail giving an error condition? fsck could then just pick another block for allocation, flagging the original block as bad so the administrator could take care of it. Some more questions: Would fsck really be able to find out if the block is "bad" just by reading it? Even through the block device interface? Also, what does 4.2 BSD do with bad blocks if it doesn't link them to inode 1? Do you reformat the disk and map around them? That seems a bit extreme. I'm really curious about this and would appreciate any feedback anyone could give me. Thanks. -- Breck Beatie uunet!aimt!breck
roy@phri.UUCP (Roy Smith) (08/22/87)
In article <657@hplabsz.HPL.HP.COM> mayer@hplabsz.UUCP (Niels Mayer) writes: > I vaguely know what the lost+found directory does for a disk partition. Can > someone explain the reason for needing 100 empty files in the directory? You don't need empty files in the directory, but empty slots. It goes like this. When you make a file, the directory gets an entry in it containing the file name and the inode number. When you remove a file, the inode number is set to zero, which indicates that the directory slot is unused. Next time you go to create a file, if there are any unused slots, the kernel will reuse a slot. If there aren't any empty slots, the kernel will grow the directory and make a new slot. Fsck knows how to take unreferenced files and put them in /lost+found, with made-up names (#i, where i is the inode number). It does not know, however, how to grow a directory, so if it has to reattach a file and there aren't any empty slots in the lost+found directory, you're screwed. So, when you create a lost+found, you make lots of empty files there and then remove them all, leaving lots of empty slots for fsck to use if it ever has to. Since directories don't shrink, these slots stay around, empty, until needed. With the coming of 4.3, some of this has changed. Fsck is supposed to know how to grow directories, and directories are supposed to be able to shrink under the right conditions. As somebody has already pointed out, given that you are working with a addled file system to begin with, you probably shouldn't trust that fsck can grow the lost+found directory if it has to. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
ed@mtxinu.UUCP (Ed Gould) (08/22/87)
>I vaguely know what the lost+found directory does for a disk partition. Can >someone explain the reason for needing 100 empty files in the directory? >What happens if you just do mkdir <partition>/lost+found and leave it at that? The lost+found directory is used by fsck to recover "lost" files and directories. When it finds an allocated file with no name, it will (potentially) link it into the lost+found directory. However, since fsck does not yet know that the filesystem is in a consistent state, it doesn't want to allocate any new space to lost+found. Hence the need to create lots of empty slots. The fsck that comes with 4.3bsd has been improved in this regard, but newfs (mkfs) still creates 4K- or 8K-byte lost+found directories. -- Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
tgr@picuxa.UUCP (Dr. Emilio Lizardo) (08/25/87)
According to the System V Admin Guide (c) 1985, pg 3-34, 3-35:
"As a general guide, the number of [i-node] slots to reserve
is about ten percent of the number of i-nodes allocated for
the file system."
The following shell script accepts as argument $1 the number of
inodes in the file system, then creates files in modulo 50 increments
up to 10% of the argument. Your current directory should be
the empty file system.
Note: the "rm" statements at the end of this script may blow up if the
file system is sufficiently large (error is "arg list too big" or
some such nonsense). If this happens, change the lines to:
rm [A-M][0-9]*
rm [M-Z][0-9]* etc.
or just try rm *
---------cut here------------
if [ "${#}" -gt "1" ] | [ "${#}" = "0" ]
then
echo "Usage: $0 n"
echo " where n = number of i-nodes in file system."
exit 1
fi
# Loop for mod 50 of 10% of $1
n=`expr \( \( $1 / 10 \) +1 \) /50`
if [ "$n" = "0" ]
then
n=1
fi
# Create 50 files at a time
while [ "${n}" -gt "0" ]
do
>a${n}; >b${n}; >c${n}; >d${n}; >e${n}
>f${n}; >g${n}; >h${n}; >i${n}; >j${n}
>k${n}; >l${n}; >m${n}; >n${n}; >o${n}
>p${n}; >q${n}; >r${n}; >s${n}; >t${n}
>u${n}; >v${n}; >w${n}; >x${n}; >y${n}
>A${n}; >B${n}; >C${n}; >D${n}; >E${n}
>F${n}; >G${n}; >H${n}; >I${n}; >J${n}
>K${n}; >L${n}; >M${n}; >N${n}; >O${n}
>P${n}; >Q${n}; >R${n}; >S${n}; >T${n}
>U${n}; >V${n}; >W${n}; >X${n}; >Y${n}
n=`expr ${n} - 1`
done
# Now remove files
echo "Removing files..."
rm [A-Z][0-9]*
rm [a-z][0-9]*
exit
--
Tom Gillespie ( ...ihnp4!picuxa!tgr) | "Don't take life so serious...
AT&T/EDS Product Integration Center | it ain't nohow permanent."
299 Jefferson Rd. |
Parsippany, NJ 07054 (201) 952-1178 | Walt Kellymolly@killer.UUCP (Molly Fredericks) (08/25/87)
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! I try to be real careful before I RTFM anyone (my mother doesn't let me talk dirty except to assholes ;-) The three different manuals I have don't give an entry for mklost+found(8). The manuals are: Unix 7th Edition Unix System III Unix Release 5.0 (the white book) I don't think the System V Release 2 manuals at work are going to be much different. Of course, I'm not stupid, maybe this is yet another plot by all of those silly college students as UCB that want to get their name on a BSD. New rule before posting a RTFM: Specify which manual! Molly -- Molly Fredericks UUCP: { any place real }!ihnp4!killer!molly Disclaimer: Neither me, nor my cat, had anything to do with any of this "I love giving my cat a bath, except for all those hairs I get on my tongue" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dave@murphy.UUCP (Dave Cornutt) (08/27/87)
In article <1406@killer.UUCP>, molly@killer.UUCP writes: > I try to be real careful before I RTFM anyone (my mother doesn't let me talk > dirty except to ;-) Good for you. (No sarcasm intended, either.) > The three different manuals I have don't give an entry for mklost+found(8). > The manuals are: > > Unix 7th Edition > Unix System III > Unix Release 5.0 (the white book) I think it's a Berkeleyism. It appeared in 4.2. I have no explanation for what happened to it on SunOS 3.2; it's not there, either the thing itself or the manpage. I checked the one on our Gould PN9080 (UTX 2.0) and it had a 1980 UCB copyright. It's just a shell script, and it works essentially the same way as the one Chris Torek posted -- no secret system calls, just a mkdir and then create a bunch of files and remove them. > New rule before posting a RTFM: Specify which manual! Excellent idea. --- "I dare you to play this record" -- Ebn-Ozn Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL [Ignore header, mail to these addresses] UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt ARPA: dcornutt@gswd-vms.arpa "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."