rjd@occrsh.ATT.COM (01/18/88)
>mkdir /lost+found >cd /lost+found >for i in 1 to 64 >do >cat >tmp$i <<FUNKYSTUFF >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 <create file text> 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
ted@cbterra.ATT.COM (Ted Aseltine) (01/21/88)
The discussions so far on creating an lost+found directory have given solutions which are a bit too complex. My favorite method is to find a directory which has a large number of files (e.g., /bin or /usr/bin) in the filesystem on which you want your lost+found directory, then link the files from the big directory to the lost+found. E.g., if you are have a filesystem mounted it on /mnt, and the big directory is in /mnt/bin, do the following: cd /mnt mkdir lost+found ln bin/* lost+found rm lost+found/* It is faster, and saves wear and tear on the disk.
tlh@pbhyf.UUCP (Lee Hounshell) (01/21/88)
In article <144800017@occrsh.ATT.COM> rjd@occrsh.ATT.COM writes: > 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? Yeah.. so was mine, and fsck reconnected about 10 files for me with no problems about 3 weeks ago. I suspect that the directory slot stuff is only specific to Berkeley unix.. it certainly isn't needed for the 3B1. comments? Lee Hounshell
allbery@axcess.UUCP (Brandon S. Allbery) (01/29/88)
In article <2700@pbhyf.UUCP>, tlh@pbhyf.UUCP (Lee Hounshell) writes: +--------------- | In article <144800017@occrsh.ATT.COM> rjd@occrsh.ATT.COM writes: | > 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 | | Yeah.. so was mine, and fsck reconnected about 10 files for me with no | problems about 3 weeks ago. I suspect that the directory slot stuff is | only specific to Berkeley unix.. it certainly isn't needed for the 3B1. +--------------- The reason you want preallocated blocks is that fsck has to allocate blocks from the free list otherwise. But free list repairs are the LAST thing done... so if a block is on the free list by mistake (i.e. also allocated to a file) you'll end up with even worse corruption. -- ___ ________________, Brandon S. Allbery cbosgd \ ' \/ __ __, __, aXcess Company mandrill| __ | /__> <__ <__ 6615 Center St. #A1-105 !ncoast! / ` | \__. .__> .__> Mentor, OH 44060-4101 necntc | axcess!allbery \___/\________________. Moderator, comp.sources.misc hoptoad/