Hallo. Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote: |Steffen Nurpmeso <stef...@sdaoden.eu> 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
