Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!occrsh!occrsh.ATT.COM!rjd From: rjd@occrsh.ATT.COM Newsgroups: comp.sys.att Subject: Re: Recommendation to mkdir /lost+f Message-ID: <144800017@occrsh.ATT.COM> Date: 18 Jan 88 14:45:00 GMT References: <178@shlepper.ATT.COM> Lines: 44 Nf-ID: #R:shlepper.ATT.COM:-17800:occrsh.ATT.COM:144800017:000:1492 Nf-From: occrsh.ATT.COM!rjd Jan 18 08:45:00 1988 >mkdir /lost+found >cd /lost+found >for i in 1 to 64 >do >cat >tmp$i <dummy line >FUNKYSTUFF >done >rm tmp* Just a comment: The line "for i in 1 to 64" will not work as written in any shell I know of. Maybe this was to be taken for granted, but the line would have to be for i in 1 2 3 4 5 6 7 8 9 10 <....on up to 64> i.e., each number on the line, otherwise you will end up with three files in the directory, "tmp1", "tmpto", "tmp64", which will not have done what you intended, and be removed before you would be able to notice it. As a check, the character length of the lost+found directory entry should be 1056 with the above corrected program (not 80). [16 bytes per entry * 64 entries, plus the entries for "." and "..".] This is assuming AT&T System V unix, release 2 or above (for that matter, on a 3B2, 3B5, or 3B15). you might try: NUM=0 while [ $NUM -lt 64 ] do NUM=`expr $NUM + 1` done On the same note: I was a little fuzzy why fsck required already-made but empty directory entries or allocated blocks. I seem to recall that my lost+found directory was 32 characters (the minimum, just the . and .. entries) prior to fsck being run and finding 5 disconnected files that were reconnected just fine (I happened to have an ls -l output of the / filesystem before the crash which showed the 32 character lost+found entry). I will grant that Berkley unix may need the entries, but is this really true for AT&T System V? Randy