
GNU tar blocking factor, blocks, records and checkpoints - mfincham
https://finch.am/projects/tar/
======
throw0101a
> _Because tar operations may be long running, it can be useful to have
> feedback about progress during the operation._

For those running on a system that has SIGINFO (e.g., BSD, macOS?), hit ^T and
you'll get a status report to stderr. ^T should work for various other
utilities as well: dd, cp, ftp.

On those systems that do not have SIGINFO (Linux?), but are using _bsdtar_
(libarchive), SIGUSR1 will do the same:

* [https://github.com/libarchive/libarchive/search?q=SIGINFO](https://github.com/libarchive/libarchive/search?q=SIGINFO)

INFO isn't one of the mandatory POSIX signals:

* [https://en.wikipedia.org/wiki/Signal_(IPC)#POSIX_signals](https://en.wikipedia.org/wiki/Signal_\(IPC\)#POSIX_signals)

~~~
LukeShu
I'm a GNU fanboy, but I've given in that (libarchive) bsdtar is just nicer
than GNU tar

------
kevin_thibedeau
Tar is a convenient format for basic embedded data storage since it's easy to
parse and you don't have to build custom tooling to prepare them. We'd store
small pre-gzipped web resources in a tar file and send them out as is without
needing onboard compression. The blocking factor puzzled me for a bit when I
was trying to store a few hundred bytes and couldn't understand where the
extra 10k was coming from. Sometimes you have to RTFM.

~~~
bestouff
I wrote an incomplete tar parser (genext2fs author here) because I also
thought tar was easy. Believe me nothing could be more wrong. That old
underspecified file format is full of weird addons by different
implementations, bug workarounds, it's big and hard to get right.

Eventually I gave in and added libarchive as an alternative.

~~~
kevin_thibedeau
If you stick to the modern format it's simple. If you are only using modern
tooling there's no need to support the legacy headers.

