[Module::Build] [rt.cpan.org #18720] [PATCH] Archive::Tar creates POSIX style tar files unnecessarily and by default, leading to compatibility problems particularly with WinZip.

[v. R. <bug...@rt...>]

<URL: http://rt.cpan.org/Ticket/Display.html?id=3D18720 >

On Fri Apr 14 12:27:43 2006, YVES wrote:
> 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.

This is a good point you raise, and seems like something worth fixing.
However, since the patch you attached addresses many more issues than
just this one, i'ts hard to decipher which parts would need to be applied=
.

I'd be interested in a patch for just this particular issue.

> 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 lon=
g
> 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.

I've done quite a bit of thinking about this, and have asked various othe=
rs
for their input in this, as well as testing the possible scenarios. In th=
e end,
I've decided that the patch as it is will not be applied, for the followi=
ng reasons:

* POSIX-tar is the standard tar on many unix filesystems, including Solar=
is,
IRIX and AIX. Applying this change will break all A::T generated tar file=
s for
those platforms. This is not only a backwards incompatible change, but wi=
ll
cripple their use of tools such as CPAN.pm and CPANPLUS.

* On Win32, installation tools such as CPAN.pm and CPANPLUS use Archive::=
Tar
or cygwin's /bin/tar, which both support POSIX and GNU-tar file formats, =
so their
use of the CPAN installers will not be hampered.

* Archive::Tar already supports a way to change the POSIX-compliant archi=
ves
to GNU-style archives. Users worried about these issues have the choice t=
o do
the right thing for their Win32 users, without breaking backward compatib=
ility
of Archive::Tar.
Since this behaviour may not be 100% apparent to the novice user, I have =
added
a FAQ entry about this particalur issue (See below)

* Changing of the global variable C<$DO_NOT_USE_PREFIX> is also a backwar=
ds
incompatible change, which, unless unavoidable, should not be done as it =
will
break peoples existing code.

Here's the docpatch i've applied to inform users of the issues involving =
the use of
A::T, and the intricacies of the tar format itself:

1432,1438c1432,1443
< By default, C<Archive::Tar> will try to put paths that are over
< 100 characters in the C<prefix> field of your tar header. However,
< some older tar programs do not implement this spec. To retain
< compatibility with these older versions, you can set the
< C<$DO_NOT_USE_PREFIX> variable to a true value, and C<Archive::Tar>
< will use an alternate way of dealing with paths over 100 characters
< by using the C<GNU Extended Header> feature.
---
> By default, C<Archive::Tar> will try to put paths that are over=20
> 100 characters in the C<prefix> field of your tar header, as
> defined per POSIX-standard. However, some (older) tar programs=20
> do not implement this spec. To retain compatibility with these older=20
> or non-POSIX compliant versions, you can set the C<$DO_NOT_USE_PREFIX>=20
> variable to a true value, and C<Archive::Tar> will use an alternate=20
> way of dealing with paths over 100 characters by using the=20
> C<GNU Extended Header> feature.
>=20
> Note that clients who do not support the C<GNU Extended Header>
> feature will not be able to read these archives. Such clients include
> tars on C<Solaris>, C<Irix> and C<AIX>.
1539a1545,1555
> =3Ditem I'm using WinZip, or some other non-POSIX client, and files are=
 not being extracted=20
properly!
>=20
> By default, C<Archive::Tar> is in a completely POSIX-compatible
> mode, which uses the POSIX-specification of C<tar> to store files.
> For paths greather than 100 characters, this is done using the
> C<POSIX header prefix>. Non-POSIX-compatible clients may not support
> this part of the specification, and may only support the C<GNU Extended
> Header> functionality. To facilitate those clients, you can set the
> C<$Archive::Tar::DO_NOT_USE_PREFIX> variable to C<true>. See the=20
> C<GLOBAL VARIABLES> section for details on this variable.
>=20
1621a1638,1662
> =3Dhead1 SEE ALSO
>=20
> =3Dover 4
>=20
> =3Ditem The GNU tar specification
>=20
> C<http://www.gnu.org/software/tar/manual/tar.html>
>=20
> =3Ditem The PAX format specication
>=20
> The specifcation which tar derives from; C< http://www.opengroup.org/on=
linepubs/
007904975/utilities/pax.html>
>=20
> =3Ditem A comparison of GNU and POSIX tar standards; C<http://www.delor=
ie.com/gnu/
docs/tar/tar_114.html>
>=20
> =3Ditem GNU tar intends to switch to POSIX compatibility
>=20
> GNU Tar authors have expressed their intention to become completely
> POSIX-compatible; C<http://www.gnu.org/software/tar/manual/html_node/
Formats.html>
>=20
> =3Ditem A Comparison between various tar implementations
>=20
> Lists known issues and incompatibilities; C<http://gd.tuwien.ac.at/util=
s/archivers/star/
README.otherbugs>
>=20
> =3Dback
>=20