🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.sysadmin
Article #1553

tricking dump to not dump files

#1553
From: Peter Rayner
Date: Fri, 16 Oct 1992 19:43
42 lines
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!pjr

Show 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