Skip Menu |
 

This queue is for tickets about the Archive-Extract CPAN distribution.

Report information
The Basics
Id: 16827
Status: resolved
Priority: 0/
Queue: Archive-Extract

People
Owner: Nobody in particular
Requestors: adamk [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.07
Fixed in: (no value)



Subject: ->extract_path and ->files are unreliable
Download (untitled) / with headers
text/plain 1.3k
After an extraction, ->extract_path sometimes does some magical things. If I extract( to => 'foo' ), then ->extract_path will be either 'foo' or 'foo/bar' depending on the archive type. Furthermore, the relationship between ->extract_path and ->files is not consistent. Sometimes you can just add an entry from->files onto ->extract_path, and sometimes you can't. The problem is caused by Archive::Extract::_untar_at(/usr/local/share/perl/5.8.4/Archive/Extract.pm:548): 548: my $test = File::Spec->rel2abs( $files[0] ); DB<3> Archive::Extract::_untar_at(/usr/local/share/perl/5.8.4/Archive/Extract.pm:549): 549: my $dir = -d $test ? $test : dirname($test); This seems to want to "have it's cake and eat it too". It first sets the extract_path magically to a subdirectory, if the first element in the tarball is a subdirectory, but having changed it's mind about where the base is, doesn't update the file list to strip the leading directory. Now, I'm happy either way (magic or non-magic) but you need to make the results more consistent. I'm ending up with ->extract_path being '...../Class-Foo-1.23' and the files list being [ 'Class-Foo.123/', ... ]. Sometimes they match, sometimes they don't. Sometimes extract_path returns the 'to' dir, sometimes a magic subdir... Please fix one. Either remove the subdir magic or update the files list. Thanks
Download (untitled) / with headers
text/plain 2.1k
On Sat Dec 31 03:12:59 2005, ADAMK wrote: Show quoted text
> After an extraction, ->extract_path sometimes does some magical > things. > > If I extract( to => 'foo' ), then ->extract_path will be either 'foo' > or 'foo/bar' depending on the archive type. > > Furthermore, the relationship between ->extract_path and ->files is > not consistent. > > Sometimes you can just add an entry from->files onto ->extract_path, > and sometimes you can't. > > The problem is caused by > > Archive::Extract::_untar_at(/usr/local/share/perl/5.8.4/Archive/Extract.pm:548): > 548: my $test = File::Spec->rel2abs( $files[0] ); > DB<3> > Archive::Extract::_untar_at(/usr/local/share/perl/5.8.4/Archive/Extract.pm:549): > 549: my $dir = -d $test ? $test : dirname($test); > > > > This seems to want to "have it's cake and eat it too". > > It first sets the extract_path magically to a subdirectory, if the > first element in the tarball is a subdirectory, but having changed > it's mind about where the base is, doesn't update the file list to > strip the leading directory. > > Now, I'm happy either way (magic or non-magic) but you need to make > the results more consistent. > > I'm ending up with ->extract_path being '...../Class-Foo-1.23' and the > files list being [ 'Class-Foo.123/', ... ]. > > Sometimes they match, sometimes they don't. Sometimes extract_path > returns the 'to' dir, sometimes a magic subdir... > > Please fix one. Either remove the subdir magic or update the files > list.
The extract_path determining magic has been fixed, so that htese situations should not be ambigious anymore. Further more, the documentation got updated, which is particularly relevant to your situation: =head2 $ae->extract( [to => '/output/path'] ) [...] =item $ae->files This is an array ref with the paths of all the files in the archive, relative to the C<to> argument you specified. To get the full path to an extracted file, you would use: File::Spec->catfile( $to, $ae->files->[0] ); Note that all files from a tar archive will be in unix format, as per the tar specification. =back So a concatenation of extract_path and files is not usually valid. Hope this fixes your issue,


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.