in reply to Re: Problem with Archive::Tar created archives and Winzip
in thread Problem with Archive::Tar created archives and Winzip

Regardless I have to say this particular subject annoys me no end

I must say that I was pretty amazed (and still am) to find that I can:
$tar->read('orig.tar', 0); #read orig.tar into memory $tar->write('copy.tar, 0); #write copy.tar from memory
and end up with a copy.tar that's not identical to orig.tar. (Of course, that doesn't happen if $Archive::Tar::DO_NOT_USE_PREFIX is set.)

You can also find my patch to Archive::Tar

Does the application of that patch achieve something that setting $Archive::Tar::DO_NOT_USE_PREFIX fails to achieve ?

Cheers,
Rob

Replies are listed 'Best First'.
Re^3: Problem with Archive::Tar created archives and Winzip
by demerphq (Chancellor) on Jul 24, 2007 at 09:02 UTC

    Afair the patch does the following:

    1. Uses the traditional single field for the name when the name of a file and its path will fit into the original 100 char name field. This is the safest option if its available as it means the tar file can be read even by very old tars that know neither the GNU nor the POSIX format. In other words it bypasses the whole POSIX/GNU debate entirely for a vast majority of use.
    2. Adds support for the GNU long file format which is currently unsupported by A::T. That is where a file with a long name is represented by two file records in the tar. The first record has a funky special name that tells tar that the name is in fact embedded in the (variable size) data portion, and the second has a similar label but the data portion has the file contents. This format allows filespecs of arbitrary size, not the braindamaged "we'll give you another 100 characters -- that should be enough" POSIX format.
    3. Changes the default long filename support format to GNU so that it will not produce POSIX file formats without being explicitly asked to. IME tar utilities that grok the GNU format are more common than ones that grok POSIX, although any new version of GNU tar will handle both correctly.

    In fact it is probably the first change that is the most important and useful. IMO its not that common to pack files whose packed path is longer than 100 chars, and as such its preferable to produce a tar which can be read by anything. As Larry has said: "be liberal with what you accept and conservative with what you produce". A::T should follow suit.

    ---
    $world=~s/war/peace/g