[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] Just updated debian wheezy to wheezy-backports, tar now 1.
From: |
Gene Heskett |
Subject: |
Re: [Bug-tar] Just updated debian wheezy to wheezy-backports, tar now 1.27-1 |
Date: |
Tue, 12 Jan 2016 10:10:41 -0500 |
User-agent: |
KMail/1.9.10 (enterprise35 0.20100827.1168748) |
On Tuesday 12 January 2016 05:34:00 Gene Heskett wrote:
> Greetings;
>
> Thats one update that I would have unchecked had I noted it was going
> to be done in the midst of 330 other packages.
>
> So now I have to figure out whats broken that did work just fine with
> wheezy's 1.26-whatever.
>
> Why pray tell, can't we ever have a tar update that does NOT break
> existing configurations that have worked well for several years?
>
> Cheers, Gene Heskett
To further clarify now that I've input some coffee, I have the amanda
backup program wrapped up in a couple scripts that bring the actual
stored data up to the point where a bare metal recovery to the exact
condition the system was in at the end of THIS run, as opposed to its
not being available until after the next run. The whole MaryAnn lives
in /GenesAmandaHelper-0.61, and a finishing subscript is called from
the main script to manage both the record keeping, and make the indices
and configs that made that backup, effectively part of that backup
should the unthinkable happen.
Anyway, this script has been launching tar to generate the copies
needed, and place them on the end of that same tape if there is room,
or in my case, in the same directory, called a virtual tape by amanda,
on a separate big hard drive, which I have found is far more dependable
than any tape drive I can afford, and because the hard drive is random
access, nominally 1000 times faster to accomplish the recovery.
The lines in that script that have been broken by the new (to me, running
debian wheezy) version 1.27-1 are all:
tar -cpsf indices.tar.${TAPENAME} $INDICE_PATH 2>&1 >> dd.report$TAPENAME
tar -cpsf configuration.tar.${TAPENAME} $CONFPATH 2>&1 >> dd.report.$TAPENAME
And after many years of running that way, tar is now sticking out its
tongue and sharpening its finger pointed at me with the following mes-
sages in the report:
tar: --same-order option cannot be used with -c
Try 'tar --help' or 'tar --usage' for more information
Which is, shall we say from doing that, conciderably less than helpfull.
So why is the -cpsf argument now illegal? And better yet, how do I fix
it in a 100% backwards compatible manner? Or do I have to, once its
fixed so this tar is happy, restart my backups to generate a brand new
750 Gigabyte database from square one? That would leave me exposed to
losing about 13 years worth of data for about a week if it couldn't be
worked around.
Thank you all.
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>