4 ms·
Of course, if you care about (random access) performance you aren’t using that, either. I don’t really understand why anyone uses tar anymore, really.
by TylerE 4y ago
Of course, if you care about (random access) performance you aren’t using that, either. I don’t really understand why anyone uses tar anymore, really.
- awestroke 4y agoWhat would you use instead of tar?
- selfhoster11 4y agoZIP with LZMA compression is one possibility. Random seek were always supported, and later versions also gained support for modern encryption, modern compression, and IIRC Unix permissions too.
- wruza 4y agoZIP always had filename encoding issues, afair. At least in a “real-world zip”. Have they been resolved? (And does tar have them?)
- deleted 4y ago[deleted]
- pastage 4y agoIf you use pax format all metadata is assumed to be UTF-8. So that would work with tar.
- account42 4y agoZIP with non-deflate compression is just silly. If you are not going to create defacto-standard compatible .zips then you might as well use a better archiving format.
- selfhoster11 4y agoYour choice of tools always depends on the use case. If you're only going to be creating these archives for internal use, or will be exchanging them/reading them on modern Unix-like systems, then there is no worry about the decompressor not supporting LZMA. If you need to exchange files with feature-poor systems, then yes - stick to the de-facto standard. Besides, what "better" archiving format are you going to use? Tar clearly isn't one (the great... grandparent comment wouldn't be asking for alternatives if it were). "Defacto standard" ZIP files have a poor compression ratio. 7z feels strange to use in a professional setting or for long-term storage. RAR is a closed-source abomination. Are there any other "better" archiving formats that have wider (de)compressor adoption than ZIP+LZMA?
- zelphirkalt 4y agoTAR makes multiple things into one thing, so that repetitions in those things will cause compression gains. Not sure how the other compression algos work, but at least when gzipping, you will not gain that compression, if the repetitions are in separate files. So first TAR then gzip has been the standard way of doing it.
- selfhoster11 4y agoTar is the standard. It's pretty easy to produce and consume tar archives on Unix-like systems (especially in a streaming fashion, which comes in handy if your storage is scratch storage is slow/tiny for some reason), and a lot of software will just work with it. Other than that, tar is still frequently used for packing data to be recorded onto LTO tapes (even despite LTFS being a thing).
- usefulcat 4y agoIf you need or want to use tar and compression, you can consider pixz. It's compatible with xz, can do multithreaded compression and decompression, and can efficiently extract a single member from a .tar.xz archive without having to decompress the entire archive. xz/pixz is much more computationally expensive than zstd or gzip but also provides better compression ratios.
- bheadmaster 4y agoTar is not a compression algorithm, it is a format for serializing files, so it covers a different use-space. I've used it often to speed up transfers of many small files over SSH - scp always took a small amount of time before sending each file, and with many files, the wasted time blew up. Serializing all those files with tar and deserializing them on the other side turned out to be much faster, especially since tar works in a stream-like fashion. And it's convenient to type, too: tar -c path/to/file1 path/to/file2 ... | ssh user@host tar -x