Fetch Support for tar GNUTYPE_LONGNAME chunks

[dasimmet]

adds gnu tar FileTypes and handle GNUTYPE_LONGNAME by reading the next chunks into the filename buffer

test case:

$ zig fetch https://www.python.org/ftp/python/3.12.0/Python-3.12.0.tgz
1220862c0e5172fddd0095ea7d08c14beb6079c45d8750a016da45ab12745e7d876a

$ mkdir build
$ curl -L https://www.python.org/ftp/python/3.12.0/Python-3.12.0.tgz | gunzip | tar x -C build

$ diff -r ~/.cache/zig/p/1220862c0e5172fddd0095ea7d08c14beb6079c45d8750a016da45ab12745e7d876a/ build/Python-3.12.0/
$

still missing GNUTYPE_LONGLINK support

[truemedian]

Where is this name guaranteed? And why is this enum field not consistent with the rest?

[dasimmet]

the name is mentioned here: https://ftp.gnu.org/old-gnu/Manuals/tar-1.12/html_node/tar_117.html
but i guess this check can be removed as the type should be enough to assume the following chunks to be a filename.

I just matched the Globals in the GNU standard. By "consistent", you mean it should be lowercased, without "GNUTYPE_", or what do you propose?
I thought it may be useful to be able to distinguish which standards the different values come from.

[truemedian]

The filename seems to be nothing more than a fallback for tar implmentations that don't handle GNU fields, a longname header is identified uniquely by the type.

At the very least the enum fields should follow the style guide and be lowercase.

[truemedian]

Is there a reason you don't simply read the data straight into the filename buffer?

[dasimmet]

i'll try it, thanks. Its just what I came up with thinking not advancing the header buffer may cause issues

[dasimmet]

after looking into it, one reason to do it this way could be if we barely reach MAX_PATH_BYTES, the 512 byte padding or next chunk could overflow the filename buffer.
It is highly unlikely though, as MAX_PATH_BYTES probably is always a multiple of 512, only a path with exactly MAX_PATH_BYTES will need to read another chunk from the stream to find the null terminator and overflow the buffer

[truemedian]

The unpadded length of the longname is given in the header, if it's more than MAX_PATH_BYTES, throw an error.

[andrewrk]

Solved instead by #18261 which included tests.