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