tricking dump to not dump files

Thread View: comp.sys.next.sysadmin

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Peter Rayner Fri, 16 Oct 1992 19:43

#1553

Author: 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

Re: tricking dump to not dump files

#1555

Author: Scott S. Bertilson
Date: Fri, 16 Oct 1992 22:50

13 lines
1391 bytes

  Well, there *is* a way, but it is really sleazy.  It turns
out that NeXT has added a hack to "dump" which causes it to
look at the list of swap files in "/etc/swaptab" and leave
them out of the backup.  I just tested it to be sure and
found that I could just tack my list of files to be excluded
onto the end of the file (no special formatting needed) and
they were left off the backup.  I suppose it could be rather
unfortunate if that list of files is still there when you
boot and "mach_swapon" runs - I don't know whether it will
try to use them without the extra sugar.  Perhaps if you use
this, you should add a little hack to "/etc/rc" to guarantee
that the gunk is eliminated before "mach_swapon" runs.
--

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads