Article View: comp.sys.next.sysadmin
Article #1553tricking dump to not dump files
From: Peter Rayner
Date: Fri, 16 Oct 1992 19:43
Date: Fri, 16 Oct 1992 19:43
42 lines
2843 bytes
2843 bytes
Perhaps this question belongs on a generic UNIX admin group but we'll start here, I'm sorry about the cross-posting too but it's half an admin and half a programming issue. For reasons of my own I want to incrementally dump a filesystem to a file *ON THAT FILESYSTEM*. You might worry that this causes an infinite loop, fortunately not since dump checks the sizes out fairly early in the piece it would appear. So in general this works. However in order to keep the dump small enough to occasionally transfer to a finite number of diskettes (say once a week in a ring buffer arrangement) and because I want a new file every day I want to avoid dumping the dump files themselves. Perhaps an example would help on Sunday I dump to a file day.0 in some directory. On Monday I do a dump at the same level but to day.1. Normally day.1 will contain a dump of day.0 and it's this I want to avoid. NeXT provide a helpful hint about how to do this involving changing the file information so that dump thinks it hasn't been modified for a long time. To me this sounds or at least sounded a lot like the utimes system call. So, I wrote a *very* small program which optionally takes a time argument (default the epoch) and sets the modification time of the rest of its arguments to that time. Finally it calls sync(2). Is this elegant? No, not really but it does work, i.e after applying it to a file with a time argument of 1000000 it says the file was modified some time in January 1970, just after the beginning of the universe 8-) Now I have done a level 0 dump since then, I think it was the early Cretaceous. So, I apply this program to day.0 in my above example thus rendering it immune from dumping yes? No. It still gets dumped right along with everything else which has been changed since the last level 0. My theory (which is mine) on this is that dump is actually looking at the inode-changed time. Can anyone confirm this? Can anyone suggest an alternative approach to tricking dump? Thanks in advance and all that -- Peter Rayner Program in Oceanic | "All right, I retract, the and Atmospheric Sciences Princeton | Honourable Member does *not* have University | the brains of a monkey." F.Daly
Technical Details
Message-ID:
<1992Oct16.194343.24190@Princeton.EDU>Path:
arc1-ca.pugleaf.net!sparky!uunet!know!hri.com!ukma!gatech!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!jvnc.net!princeton!splash!pjrShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!know!hri.com!ukma!gatech!swrinde!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!jvnc.net!princeton!splash!pjr From: pjr@splash.Princeton.EDU (Peter Rayner) Newsgroups: comp.sys.next.sysadmin,comp.sys.next.programmer Subject: tricking dump to not dump files Message-ID: <1992Oct16.194343.24190@Princeton.EDU> Date: 16 Oct 92 19:43:43 GMT Sender: news@Princeton.EDU (USENET News System) Organization: Princeton University Lines: 42 Originator: news@nimaster Nntp-Posting-Host: splash.princeton.edu