Some implementations of the tar format use these headers for long (> 100 character) file names (we ran into this with NPM packages, for example). As currently implemented, SharpCompress exposes the archiver-implementation-defined name in Entry.Key (which may not be unique due to truncation) for such archives since it is not aware of the Pax extended header format; this leads to issues like duplicate and non-representative file names when attempting to extract these archives.
The Tar implementation has support for long file names using the
'L'type flag and Pax extended global headers using the'g'type flag, but not Pax extended file headers using the'x'type flag.Some implementations of the tar format use these headers for long (> 100 character) file names (we ran into this with NPM packages, for example). As currently implemented, SharpCompress exposes the archiver-implementation-defined name in
Entry.Key(which may not be unique due to truncation) for such archives since it is not aware of the Pax extended header format; this leads to issues like duplicate and non-representative file names when attempting to extract these archives.See this reference for the Pax archive format. Implementation would require adding support for the
'x'header type flag, and overwriting or adding various extended fields specified by this format. Notably some of these extended fields are already supported, but others offer opportunity for improved archive support (file encoding, for example).