[ldx1024]

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]

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-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 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... 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.