Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!texbell!uudell!mustang!jrh From: jrh@mustang.dell.com (James Howard) Newsgroups: comp.unix.i386 Subject: Re: Interactive 2.2 File zapper. Message-ID: <7774@uudell.dell.com> Date: 26 Jul 90 00:50:19 GMT References: <772@essnj1.ESSNJAY.COM> Sender: news@uudell.dell.com Reply-To: jrh@mustang.dell.com (James Howard) Organization: Dell Computer Corp. Lines: 34 In article <772@essnj1.ESSNJAY.COM>, smitty@essnj1.ESSNJAY.COM (Hibbard T. Smith JR) writes: > Within the past 2 weeks, we've upgraded several systems from 2.0.2 to 2.2. > On one of those systems, on Sunday morning at 05:17 or thereabouts most of > the files on the system were deleted. The problem was caused by a root > crontab driven execution of /etc/cleanup. This system's /lost+found > directory was inadvertently lost during the upgrade installation, and we > we're planning on recreating it on Monday morning. > > > The last two lines of the distributed /etc/cleanup are as follows: > -- 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. Two possible fixes exist: > -- cd /lost+found && find . -mtime +14 -exec rm -rf {} \; > -- find /lost+found -mtime +14 -exec -rm {} \; > Either of these is much safer than the distributed code. This bad code is > different than 2.0.2, so beware! Well, it looks like ISC tried to fix a bug that was in 2.0.2, and created an even bigger bug. The second fix you list above has the subtle bug that was present in 2.0.2. The fix that we put in our release looks like this: touch /lost+found find /lost+found -mtime +14 -exec rm -rf {} \; >/dev/null 2>&1 without the first, /lost+found will get deleted if it hasn't been modified in 14 days. James Howard Dell Computer Corp. !'s:uunet!dell!mustang!jrh (512) 343-3480 9505 Arboretum Blvd @'s:jrh@mustang.dell.com Austin, TX 78759-7299