|CC:||"List - Module-Build" <module-build-general [...] lists.sourceforge.net>, "Perl Porters" <perl5-porters [...] perl.org>,|
|Subject:||[PATCH] Archive::Tar creates POSIX style tar files unnecessarily and by default, leading to compatibility problems particularly with WinZip.|
Archive::Tar since around version .99 has been producing files with a POSIX flavour header by default. This behaviour is undesirable as it means that the files are not readable with many Win32 based compression tools, most notably WinZip. This is especially bad as the POSIX longfile name support is used even when it needn't be, that is when the stored file name is shorter than 100 bytes. The attached patch resolves this issue (it has been open since 2003 at least), by reverting to using the original single field naming scheme when it is possible, and then falling back to the Gnu Extend Header long name file support when necessary. This removes the older $DO_NO_USE_PREFIX flag and replaces it with a flag of the opposite meaning, and with a clearer name: $POSIX_LONGFILE. IMO this is desirable because: A) POSIX long filename support appears to be restricted to paths of a maximum of 156 chars and files of 100 chars. Older versions of A::T will produce mangled tar files when these restrictions are exceeded which is in violation of the POSIX standards which mandate that a fatal error be thrown. (GNU tar itself only warns and refuses to add the file) B) Gnu Extended Header longfile support does not have a file length restriction and is correctly handled by WinZip. C) Using the single field mechansim appears to be supported by everything so when the stored paths are short there is no need to confuse things with long file naming issues. Additional changes are that I did a bit of refactoring and code clean up of dead or unnecessary code. With the patch applied all tests pass, and WinZip can correctly read the files. Open issues unresolved by this patch: Archive::Tar is much less picky about what filenames it will encode into the archive than something like gnu tar is. For instance tar will remove leading directory components that are left of or are '..', likewise normally it will convert absolute filenames to relative by removing volume and root slashes. Archive::Tar does none of this. cheers, Yves
Message body is not shown because it is too large.