Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.unix.sysv386
Subject: Re: unattended cpio backup script
Message-ID: <2679@sixhub.UUCP>
Date: 19 Dec 90 04:11:14 GMT
References: <28789@usc> <2630@sixhub.UUCP> <1990Dec17.210028.10997@chinet.chi.il.us>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 23

In article <1990Dec17.210028.10997@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:

| Unfortunately however, in the process of resetting the atime to pretend
| that you didn't read the file you set the ctime thus indicating an
| inode modification that you can't tell from some significant change
| like renaming or changing the owner or modes.  Thus, you can't mix
| using the 'a' option with doing incremental backups based on ctime.
| The only way to get both things right is to mount the fs read-only
| while doing the backup or do it across a read-only network mount.

  This is absolutely correct. Given the choice between not being able to
check the ctime, or not being able to detect files which haven't been
accessed in a year, my system administration techniques lean heavily
toward finding candidates for removal.

  This is a good point, and although I know how it works I never thought
to warn people. I'm going to write a better backup routine in December
of 91.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me