greyham@hades.OZ (Greyham Stoney) (11/28/89)
in article <4339@dell.dell.com>, jrh@mustang.dell.com (jrh) says:
% The /lost+found directory is probably there when you originally install, the
% problem is the shell script /etc/cleanup has a nasty bug in it. They have
% a line which reads:
%
% find /lost+found -mtime 14 -exec rm -rf {} \; > /dev/null 2>&1
%
% This is loaded in crontab to be executed every Sunday morning by default.
% The problem is, if /lost+found has not had it's modification time changed
% in 14 days, the entire subdirectory is removed.
.
.
.
% Next, modify /etc/cleanup to fix the problem permanently. The easiest is
% to insert a line with:
%
% touch /lost+found
%
% before the 'find' command above, should clear it up...
How about changing that line to:
find /lost+found -type f -mtime 14 -exec rm -rf {} \; > /dev/null 2>&1
^^^^^^^
since lost+found is a directory, it won't get nuked, and if there's anything
other than regular files in lost+found, they won't get nuked either.
Greyham.
--
/* Greyham Stoney: Australia: (02) 428 6476 *
* greyham@hades.oz - Ausonics Pty Ltd, Lane Cove, Sydney, Oz. *
* TDMP/IP: Telepathic Direct Marketing Personel Interface Protocol */jmm@eci386.uucp (John Macdonald) (11/29/89)
In article <479@hades.OZ> greyham@hades.OZ (Greyham Stoney) writes: |in article <4339@dell.dell.com>, jrh@mustang.dell.com (jrh) says: |% The /lost+found directory is probably there when you originally install, the |% problem is the shell script /etc/cleanup has a nasty bug in it. They have |% a line which reads: |% |% find /lost+found -mtime 14 -exec rm -rf {} \; > /dev/null 2>&1 |% |% This is loaded in crontab to be executed every Sunday morning by default. |% The problem is, if /lost+found has not had it's modification time changed |% in 14 days, the entire subdirectory is removed. |. |. |. |% Next, modify /etc/cleanup to fix the problem permanently. The easiest is |% to insert a line with: |% |% touch /lost+found |% |% before the 'find' command above, should clear it up... | |How about changing that line to: |find /lost+found -type f -mtime 14 -exec rm -rf {} \; > /dev/null 2>&1 | ^^^^^^^ | |since lost+found is a directory, it won't get nuked, and if there's anything |other than regular files in lost+found, they won't get nuked either. It would be better yet to just get rid of that line. The -mtime 14 term does not mean that the file must be in lost+found for at least 14 days before it gets turfed - it can be deleted during the same bootup sequence that runs the fsck and puts the file into lost+found, since fsck does not change mtime when it does so. Thus, if an important group of files have their directory entries corrupted (i.e. one sector of a directory got trashed), and they all get put into lost+found, then onlt the ones that have been modified in the last two weeks will survive the find/rm command. It is not nice to delete files before the sysadmin has a chance to recover them. It would be better, as an alternative, to simply test for any files in lost+found and if there are any to send mail to root or to a list of locally capable people. -- 80386 - hardware demonstrating the fractal nature of warts. | John Macdonald EMS/LIM - software demonstrating the fractal nature of warts. | jmm@eci386