4 ms·

No, the major problem of tar is 'it is not indexable'. In any case, browse a tar means you need to scan the whole achieve to locate all files and generate the e

No, the major problem of tar is 'it is not indexable'. In any case, browse a tar means you need to scan the whole achieve to locate all files and generate the entry list. And of course it get slower when the files are a lot or archive is big. This is a format even worse than zip.(Zip do have a central record section) And it also suffer the same problem from zip: the charset is undefined. Because they are older then the time utf-8 being the universal standard. Which means it mess up when two systems are in different charset and software is not smart enough to guess it. These problems are all addressed in later format(rar/7z). Newer archive format most enforcing utf-8 charset. So you won't have a problem that file name suddenly turn into garbage for no reason. It's probably the worst format you can chose if you need to distribute a file instead using it as a pack/extract on local only format(not even browse).

duskwuff 5y ago
Technically speaking, TAR is indexable -- the index is distributed through the archive, at the head of each file. So long as the TAR is uncompressed, you can skip from one header to the next by reading the size of each file. It ends up looking like a bunch of random I/O, but it's manageable. (The headers are even sector-aligned!) The problem arises when the TAR is compressed with a stream compressor (as most are). Since stream compression formats generally aren't seekable, there's no way to read each header without uncompressing the rest of the file in the process. > And it also suffer the same problem from zip: the charset is undefined. Newer archive format most enforcing utf-8 charset. On the flip side, this means that those archive formats can't archive the contents of a filesystem which contains inconsistently encoded (or flat-out nonsense) filenames. So long as filesystems haven't "solved" the encoding problem, I wouldn't fault an archive format for behaving similarly.
- mmis1000 5y ago
  > Technically speaking, TAR is indexable -- the index is distributed through the archive, at the head of each file. Actually, zip works in the same way as tar. So the central dict is locate at the end of file because it can only be decided after all works finished. And zip actually struct the first part of file with file info before every block in layout similar to tar, so stream decoding is possible. (Although it IS a violation of specification to decode file based on per file info instead of central record in zip standard) > On the flip side, this means that those archive formats can't archive the contents of a filesystem which contains inconsistently encoded (or flat-out nonsense) filenames. It is a good thing IMO because you can't contribute to the problem more now (at the price not able to backup already screwed up disks. Well..., at least old format(tar) still works on old disk)

duskwuff 5y ago

Technically speaking, TAR is indexable -- the index is distributed through the archive, at the head of each file. So long as the TAR is uncompressed, you can skip from one header to the next by reading the size of each file. It ends up looking like a bunch of random I/O, but it's manageable. (The headers are even sector-aligned!) The problem arises when the TAR is compressed with a stream compressor (as most are). Since stream compression formats generally aren't seekable, there's no way to read each header without uncompressing the rest of the file in the process. > And it also suffer the same problem from zip: the charset is undefined. Newer archive format most enforcing utf-8 charset. On the flip side, this means that those archive formats can't archive the contents of a filesystem which contains inconsistently encoded (or flat-out nonsense) filenames. So long as filesystems haven't "solved" the encoding problem, I wouldn't fault an archive format for behaving similarly.

mmis1000 5y ago
> Technically speaking, TAR is indexable -- the index is distributed through the archive, at the head of each file. Actually, zip works in the same way as tar. So the central dict is locate at the end of file because it can only be decided after all works finished. And zip actually struct the first part of file with file info before every block in layout similar to tar, so stream decoding is possible. (Although it IS a violation of specification to decode file based on per file info instead of central record in zip standard) > On the flip side, this means that those archive formats can't archive the contents of a filesystem which contains inconsistently encoded (or flat-out nonsense) filenames. It is a good thing IMO because you can't contribute to the problem more now (at the price not able to backup already screwed up disks. Well..., at least old format(tar) still works on old disk)