Re: [Bug-tar] Monthly backup doesn't expand files, but which are in the archive

[Steffen Nurpmeso]

Hallo.

Joerg Schilling <address@hidden> wrote:
 |Steffen Nurpmeso <address@hidden> wrote:
 |> I've changed it back to how it was all the time, and only use "|
 |> xargs -0 tar -r -f $ar", adding the compression step later on.
 |> As far as i recall all this originated, long ago that is, from the
 |> problem that file lists stored in a file were not supported by all
 |> tar's around and for all possible operations, and this is a real
 |> pity, given that argument lists exceed so soon, and space is
 |> expensive.  Anyway, a mode to simply concatenate, and then
 |> a finalizer invocation would be great for my use case, otherwise.
 |> Maybe i'll switch to ar(1) instead, in the future.
 |
 |A better solution may be to call:
 |
 | star -c -f some-file -find ....
 |
 |This is even faster than using find | xargs.

I started using star instead of what was on (then) MacOS
X / FreeBSD / Linux because the first time i have used it on some
tarball it spit out error messages on format incompatibilities for
tarballs of mine, a problem area i hadn't been sensitized for.
And better that is!  And sometimes it would have been better to
try it first -- i have produced some release tarballs via git
archive, before testing on NetBSD tar, for example.  No no.

Same is true for smake, by the way, it just failed in the other
window: it is really time to replace the main work machine that
died almost a year ago now.

Where was i?   Ah.  Well i could use list= of star, but that is
non-portable (the STARvsGNUTAR has some false claims btw.).
_Unfortunately_.  Really i have forgotten what the backup script
is about, but it definitely manages a timestamp on its own, and
only includes files younger than that Unix epoch says, and that is
crucial for the use case i use for so long.  Well and
(effectively) this script i carry along for a long time, over
MacOS X / FreeBSD / Linux, and it would, it would work anywhere
else out of the box, too, with whatever tar implementation there
is.  Until last October only, of course.  ._.

I know it is all silly minded.  I should use a BananaPi MP3 or so
as a file server instead, with a solar panel that drives it, that
should be no problem...  That could even be FreeBSD/ZFS;
unfortunately DragonFly/HAMMER cannot be ARM.  (But it could
inside of a KVM, of course.)  Anyway a nice filesystem with
snapshots and automatic slave synchronization to a secondary
storage.  Or Raspberry, then maybe with 9front/9atom (Plan9) and
Ken's fileserver, or whatever else.  And/or even backed by a RAID
1[0].  Really, this BananaPi is likely strong enough to do
anything i need anyway, except it is not inside a Netbook.

--steffen