GNU tar blocking factor, blocks, records and checkpoints

GNU tar blocking factor, blocks, records and checkpoints(finch.am)

27 points by mfincham 5 years ago | 5 comments

throw0101a 5 years ago |

> 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

INFO isn't one of the mandatory POSIX signals:

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

LukeShu 5 years ago | |

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

kevin_thibedeau 5 years ago |

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 5 years ago | |

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 5 years ago | | |

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.