Sorry for the SPAM, apparently RT was only getting a part of my reply.
On Tue Oct 10 00:11:46 2006, SISYPHUS wrote:
Show quoted text> This may be related to bugs 19577 and/or 18720. Sorry, I don't have a
> patch. I'm on Windows 2000, running MinGW-built perl 5.8.8 and
> Archive::Tar-1.30.
>
> By way of example, I have a tarball (test.tar.gz) that contains
> a/b/one.txt and a/b/two.txt.
> I run the following code:
>
> use warnings;
> use Archive::Tar;
> my $tar = Archive::Tar->new();
> $tar->read('test.tar.gz', 1);
> $tar->write('test2.tar.gz', 9);
>
> I would expect that test.tar.gz and test2.tar.gz would be essentially,
> if not exactly, the same. On linux this is the case, but not on Win32.
I've attempted to replicate your problem as follows:
C:\tmp\src> ls -Rl
.:
total 16
drwxr-xr-x 3 Administrator None 0 Oct 14 16:16 a
./a:
total 0
drwxr-xr-x 2 Administrator None 0 Oct 14 16:16 b
./a/b:
total 0
-rw-r--r-- 1 Administrator None 0 Oct 14 16:16 one.txt
-rw-r--r-- 1 Administrator None 0 Oct 14 16:16 two.txt
C:\tmp\srcs shows that in our original tar file, the paths are stored. Using your
copy code, i created a test2.tar, which shows exactly the same contents.
C:\tmp> cat x.pl
use strict;
use warnings;
use Archive::Tar;
my $tar = Archive::Tar->new();
$tar->read( shift() );
$tar->write( shift() );
C:\tmp> perl perl x.pl src\test.tar test2.tar
C:\tmp> ptar -tf test2.tar
a
a/b
a/b/one.txt
a/b/two.txt
So I've been unable to reproduce your problem -- the files are identical,
even according to diff(1).
I'm using vanilla-perl on Win2003 server, with Archive::Tar 1.30.
Show quoted text> On Win32, test2.tar.gz's 'one.txt' and 'two.txt' are unpacked into the
> top level destination folder - not into destination/a/b.
Hmm, also that i can not reproduce:
C:\tmp\out> ptar -xf ..\test2.tar
C:\tmp\out> ls -Rl
.:
total 0
drwxr-xr-x 3 Administrator None 0 Oct 14 17:18 a
./a:
total 0
drwxr-xr-x 2 Administrator None 0 Oct 14 17:18 b
./a/b:
total 0
-rw-r--r-- 1 Administrator None 0 Oct 14 16:16 one.txt
-rw-r--r-- 1 Administrator None 0 Oct 14 16:16 two.txt
Show quoted text> And if I open
> up test2.tar.gz in WinZip, I can see that nothing is being specified
> for "Path".
Hmm, if you are using winzip for the entire process, perhaps this FAQ
entry applies to you:
I'm using WinZip, or some other non-POSIX client, and files are
not being extracted properly!
By default, Archive::Tar is in a completely POSIX-compatible mode, which
uses the POSIX-specification of tar to store files. For paths greather
than 100 characters, this is done using the POSIX header prefix.
Non-POSIX-compatible clients may not support this part of the specification,
and may only support the GNU Extended Header functionality. To facilitate
those clients, you can set the $Archive::Tar::DO_NOT_USE_PREFIX variable
to true. See the GLOBAL VARIABLES section for details on this variable.
I'm afraid i'm not able to track down the problem for you, as it works as
intended on my windows box.
Sorry I couldn't be more help :(
If you have anything that could help me reproduce the problem, I'm happy
to look into it again -- perhaps showing me the tar files (skip the .gz
compression) generated by A::T that are faulty would help...
Regards,
-- Jos
