Xref: utzoo comp.unix.i386:7491 comp.unix.wizards:23274
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!mecky!walter
From: walter@mecky.UUCP (Walter Mecky)
Newsgroups: comp.unix.i386,comp.unix.wizards
Subject: Re: Interactive 2.2 File zapper.
Message-ID: <736@mecky.UUCP>
Date: 2 Aug 90 23:14:36 GMT
References: <772@essnj1.ESSNJAY.COM> <2108@cirrusl.UUCP>
Reply-To: walter@mecky.UUCP (Walter Mecky)
Organization: MIKROS Systemware, Buettelborn/W-Germany
Lines: 29

In article <2108@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
< >--	cd /lost+found
< >--	find . -mtime +14 -exec rm -rf {} \;
< >If there's no lost and found directory in the root file system, this deletes
< >everything in the system that's older than 14 days.

Guys, you talked about very many aspects of the problem and missed the
most important one. It was discussed here in november last year:

If fsck links a file in /lost+found, then its mtime is left unchanged.
That's true too for all the files in a directory tree if fsck links
in a directory. So, you MUST NOT use the mtime to decide if deleting
files in /lost+found because find deletes files in your filesystem you
have not changed the last 14 days. The idea behind the "find ..." 
seemed to be: delete the files and directory trees, which are longer 
than 14 days in /lost+found. 

In the november discussion were some solutions posted. I dont't
remember and don't trust anyone. In my /etc/cleanup there is
only mail produced for user root and no deletions of files:

   for i in `/etc/mount | cut -d' ' -f1`
   do
	 [ "`echo $i/lost+found/*`" = "$i/lost+found/*" ] || 
		   echo "There is something in $i/lost+found.\nLook at it!" | 
		   mail -s 'File(s) in /lost+found' root
   done
-- 
Walter Mecky	[ walter@mecky.uucp	or  ...uunet!unido!mecky!walter ]