Bug #16827 for Archive-Extract: ->extract_path and ->files are unreliable

Sat Dec 31 03:12:59 2005 adamk [...] cpan.org - Ticket created

Subject:

->extract_path and ->files are unreliable

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

Thu Jan 19 07:53:07 2006 kane [...] cpan.org - Correspondence added

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,

Thu Jan 19 07:53:08 2006 The RT System itself - Status changed from 'new' to 'open'

Thu Jan 19 07:53:08 2006 kane [...] cpan.org - Status changed from 'open' to 'resolved'