Re: [Dump-users] Problem with restore -r (and dump -m)

[Eric J. <eje...@sw...>]

Stelian Pop <st...@po...> wrote:

> > One more related question - if an RPM package installed after a level 0
> > installs a new file and sets its date to a date *before* the level 0
> > date, what will happen with that file in an incremental dump using -m ?
> > That does in fact appear to be the case for some (if not all) of the
> > "metadata only" files in the level 2 - they were installed after the
> > level 0, but have dates (as listed with 'ls -l') that are before the
> > level 0.  If this is the explanation for the "metadata only" problem, I
> > see why (and won't use -m in the future), 
> 
> I think you did indeed find the issue here. Instead of 'ls -l' do a
> 'stat' on the incriminated files and check the 'mtime'. Regular dump
> looks at both 'ctime' and 'mtime', dump -m looks only at 'mtime'.

Thanks for clearing this up - it's a wrinkle that I hadn't anticipated,
though clearly dump is functioning exactly as advertised.

If you think it's appropriate, here are a few draft sentences for
inclusion in the man page description of the "-m" switch to dump, to
help others avoid the mistake I made:

   "If you use this option, be aware that many programs that unpack
    files from archives (e.g. tar, rpm, unzip, apt) may set files'
    mtimes to dates in the past.  Files installed in this way may not be
    dumped correctly using "dump -m" if the modified mtime is earlier
    than the most recent level 0 dump."

Changes, additions, or deletions are welcome.  I'm not positive that
this is true of apt (since I don't use it), though it is true for tar,
rpm, and unzip.

Thanks,

Eric