Re: [Bug-tar] Status of feature request: ignore requested members missing in archive

[Gene Heskett]

On Tuesday 22 July 2014 09:49:38 Nathan Stratton Treadway did opine
And Gene did reply:
> On Mon, Jul 21, 2014 at 22:33:14 +0400, Vladimir A. Pavlov wrote:
> > Dear tar developers!
> > 
> > Could you please clarify the status of my previous email with a patch
> > for feature request:
> > http://lists.gnu.org/archive/html/bug-tar/2014-06/msg00003.html ?
> 
> [...]
> 
> > > The attached patch implements a new option
> > > --ignore-missing/--no-ignore-missing which allows the behavior
> > > wanted:
> > > 
> > > $ touch file
> > > $ tar -c file | tar --ignore-missing -t dir
> > > $ echo $?
> > > 0
> > > $
> 
> This reminds me that there was actually an earlier proposal for an
> "--ignore-missing" option -- in that case, to control GNU tar's
> behavior when particular files were not found as the archive was being
> created:
> 
>   http://lists.gnu.org/archive/html/bug-tar/2012-04/msg00017.html
> 
This suggestion I could offer a tip of the hat and profuse thanks for.

I have no control over when the old kmail does its expiry runs, they may 
even be semi random for all I know, but the size of the report I get an 
email about is nominally tripled by the missing emails in one kmail folder 
or another because 50 emails may have been deleted by kmails housekeeping 
between the time amanda builds a list in its estimate phase, and its 
actually doing a backup of that disklist entry 10 to 20 minutes later.  
Thats one PIMA.

And of course the 2nd bitch is its bogus bitching that file so and so is 
on a different file system and will not be backed up. Last nights report 
had several such lines, one of which I'll paste here:

  ? /usr/local/bin/tar: ./init/rw: directory is on a different filesystem; 
not dumped

It may or may not be bogus, I have no idea since there are no clues as to 
what directory tree I might find this ./init/rw in.  Locate tells me its 
/lib/init however. rw is a subdir, which in turn has only another subdir 
in it, so when I am at the end of that path, /lib/init/rw/sendsigs.omit.d
I find a link called portmap, which is a softlink to /var/run/portmap.pid.

Now, this is NOT on a "different" filesystem as this drive, a 1Tb, has 
only 3 partitions, /boot, / and swap.  Now to me a different filesystem 
would me a separate partition, that was formatted differently as if / was 
a reiserfs (but I'n not that dumb).

There are several other such error lies reported.  If I can, I'm going to 
run them all down & add them to the appropriate exclude file.

Why it upchucks and pukes out messages such as that, a full directory 
level above the actual offending link, I have no clue, but it sure makes 
my backup reports for a 30+ disklist entry hard to read, having to scroll 
down about 2 full pages of text just to read the portion of the report 
that I care about.
 
Tar's version is 1.27. Previous versions reported no such tummy aches.

> I am not sure off hand if it would make sense to control behavior for
> both create and extract using the same option or if they are different
> enough in meaning that they should be requested separately.
> 
> But in any case it seems the two requests taken together are an
> indication that it would be useful to have a more structured way to
> control what situations GNU tar treats as errors (i.e. causing it to
> exit with an error status) and what is considered just a warning.
> 
>                                               Nathan
> 
> -----------------------------------------------------------------------
> ----- Nathan Stratton Treadway  -  address@hidden  -  Mid-Atlantic
> region Ray Ontko & Co.  -  Software consulting services  -  
> http://www.ontko.com/ GPG Key:
> http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239 Key
> fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS