4 ms·
GNU tar blocking factor, blocks, records and checkpoints
- throw0101a 6y 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 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 6y agoI'm a GNU fanboy, but I've given in that (libarchive) bsdtar is just nicer than GNU tar
- kevin_thibedeau 6y agoTar 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 6y agoI 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 6y agoIf 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.