4 ms·

> Microsoft says it’s also letting File Explorer natively compress files to 7-zip and TAR; currently, the right-click context menu has a “Compress to ZIP file”

by kmoser 2y ago

> Microsoft says it’s also letting File Explorer natively compress files to 7-zip and TAR; currently, the right-click context menu has a “Compress to ZIP file” option, but ZIP is thought to be a bit antiquated in terms of how much compression you get. ZIP is antiquated...but TAR isn't?

lmm 2y ago
> ZIP is antiquated...but TAR isn't? No, because tar only does archiving and is usually combined with a separate compressor - gzip, bzip2, lzip, and no doubt new and exciting compressors that have yet to be invented. So tar (with a suitable modern compressor) is still relevant today.
- Jamie9912 2y ago
  [flagged]
- FrostKiwi 2y ago
  I agree, that it is antiquated. > suitable modern compressor I would expect a suitable modern compressor to handle files by itself and fail to handle file related things if given a tar archive.
  - MobiusHorizons 2y ago
    Block based compressors like gzip, bzip2, xz, lzma, etc don’t natively know how to compress multiple files, to them it’s just bytes in bytes out. Using these with tar allows both archive (multiple files / directories in one file) as well as compression. Such usage has the potential for higher compression ratios because it can deduplicate across the entire archive. Zip compresses each file individually, but has an uncompressed index. Tools like 7z use standard compression algorithms (I believe Lzma) with a different archive format. It’s all about how you want to integrate or customize your tools.
- jimbobthrowawy 2y ago
  Tar isn't a great archival (by which I mean combining multiple files into one file) format for most people, since it emulates tape by putting records of what file you just read right in line with the data. To access a single file from a tar, you have to read the archive sequentially until you get to the record for that file. (assuming there's only one copy of that file in there) Most other formats put data about what files are contained inside at the end of the file, so you need to read much less of it. Being able to append tar files together is a killer feature though, and it's not going anywhere.
  - ldx1024 2y ago
    Another feature of tar (the 7-zip implementation, anyway, I haven't checked others) is that it will properly archive files whose path length exceeds the path length limit, and then also restore the files properly. Conversely, trying to zip up a group of files with paths too long appears to work but then results in a corrupt zip file that will not unzip. I'm no expert in this area, but that is my recollection. So if you have any doubts about whether your files to archive have paths too long it is better to tar them then zip the tar file rather than just zip the files.
    - yjftsjthsd-h 2y ago
      Well now you got me curious... I don't know about particular implementations, but tar should support 255-character file names, with the caveat that I'm pretty sure that length includes the path (i.e. 'foo/bar.txt' is 11 chars long, it doesn't matter that 3 are in the directory prefix, and also the separating / chars do count). You can see this by reading the file format spec, ex. https://www.ibm.com/docs/en/zos/3.1.0?topic=formats-tar-format-tar-archives https://www.ibm.com/docs/en/zos/3.1.0?topic=formats-tar-form... is my personal favorite. Pretty much everyone is using the extended USTAR format, and then the overall file path+name is stored in the name field and if it's longer than 100 chars then the prefix field is used, so you get a max of 155+100=255 chars, which is probably sufficient since IIRC most moderns systems won't let you make a longer path than that on the live filesystem anyways. I'm less familiar with zip, but https://en.wikipedia.org/wiki/ZIP_(file_format)#File_headers https://en.wikipedia.org/wiki/ZIP_(file_format)#File_headers seems to say that the file name field is arbitrary, but the file name length field is 2 bytes. A little searching also turns up https://pkwaredownloads.blob.core.windows.net/pkware-general/Documentation/APPNOTE-6.3.9.TXT https://pkwaredownloads.blob.core.windows.net/pkware-general... which appears to be the official spec, which contains this: 4.4.10 file name length: (2 bytes) 4.4.11 extra field length: (2 bytes) 4.4.12 file comment length: (2 bytes) The length of the file name, extra field, and comment fields respectively. The combined length of any directory record and these three fields SHOULD NOT generally exceed 65,535 bytes. If input came from standard input, the file name length is set to zero. so my reading is actually that zip should support very long file paths. Of course, I would easily believe that in practice tar implementations handle long paths better, because software is like that.
thesuitonym 2y ago
Tarballing files if you're not gzipping, bzipping, or 7zipping them is a bit antiquated, but being able to natively open tarballs in Windows would be kind of cool.

by kmoser 2y ago

lmm 2y ago

> ZIP is antiquated...but TAR isn't? No, because tar only does archiving and is usually combined with a separate compressor - gzip, bzip2, lzip, and no doubt new and exciting compressors that have yet to be invented. So tar (with a suitable modern compressor) is still relevant today.

Jamie9912 2y ago
[flagged]
FrostKiwi 2y ago
I agree, that it is antiquated. > suitable modern compressor I would expect a suitable modern compressor to handle files by itself and fail to handle file related things if given a tar archive.
- MobiusHorizons 2y ago
  Block based compressors like gzip, bzip2, xz, lzma, etc don’t natively know how to compress multiple files, to them it’s just bytes in bytes out. Using these with tar allows both archive (multiple files / directories in one file) as well as compression. Such usage has the potential for higher compression ratios because it can deduplicate across the entire archive. Zip compresses each file individually, but has an uncompressed index. Tools like 7z use standard compression algorithms (I believe Lzma) with a different archive format. It’s all about how you want to integrate or customize your tools.
jimbobthrowawy 2y ago
Tar isn't a great archival (by which I mean combining multiple files into one file) format for most people, since it emulates tape by putting records of what file you just read right in line with the data. To access a single file from a tar, you have to read the archive sequentially until you get to the record for that file. (assuming there's only one copy of that file in there) Most other formats put data about what files are contained inside at the end of the file, so you need to read much less of it. Being able to append tar files together is a killer feature though, and it's not going anywhere.
- ldx1024 2y ago
  Another feature of tar (the 7-zip implementation, anyway, I haven't checked others) is that it will properly archive files whose path length exceeds the path length limit, and then also restore the files properly. Conversely, trying to zip up a group of files with paths too long appears to work but then results in a corrupt zip file that will not unzip. I'm no expert in this area, but that is my recollection. So if you have any doubts about whether your files to archive have paths too long it is better to tar them then zip the tar file rather than just zip the files.
  - yjftsjthsd-h 2y ago
    Well now you got me curious... I don't know about particular implementations, but tar should support 255-character file names, with the caveat that I'm pretty sure that length includes the path (i.e. 'foo/bar.txt' is 11 chars long, it doesn't matter that 3 are in the directory prefix, and also the separating / chars do count). You can see this by reading the file format spec, ex. https://www.ibm.com/docs/en/zos/3.1.0?topic=formats-tar-format-tar-archives https://www.ibm.com/docs/en/zos/3.1.0?topic=formats-tar-form... is my personal favorite. Pretty much everyone is using the extended USTAR format, and then the overall file path+name is stored in the name field and if it's longer than 100 chars then the prefix field is used, so you get a max of 155+100=255 chars, which is probably sufficient since IIRC most moderns systems won't let you make a longer path than that on the live filesystem anyways. I'm less familiar with zip, but https://en.wikipedia.org/wiki/ZIP_(file_format)#File_headers https://en.wikipedia.org/wiki/ZIP_(file_format)#File_headers seems to say that the file name field is arbitrary, but the file name length field is 2 bytes. A little searching also turns up https://pkwaredownloads.blob.core.windows.net/pkware-general/Documentation/APPNOTE-6.3.9.TXT https://pkwaredownloads.blob.core.windows.net/pkware-general... which appears to be the official spec, which contains this: 4.4.10 file name length: (2 bytes) 4.4.11 extra field length: (2 bytes) 4.4.12 file comment length: (2 bytes) The length of the file name, extra field, and comment fields respectively. The combined length of any directory record and these three fields SHOULD NOT generally exceed 65,535 bytes. If input came from standard input, the file name length is set to zero. so my reading is actually that zip should support very long file paths. Of course, I would easily believe that in practice tar implementations handle long paths better, because software is like that.

thesuitonym 2y ago

Tarballing files if you're not gzipping, bzipping, or 7zipping them is a bit antiquated, but being able to natively open tarballs in Windows would be kind of cool.