in reply to Re: Archive::Tar Memory Consumption
in thread Archive::Tar Memory Consumption

I've tried compiling .20 among all the lastest versions of this module, but none of them work, and it appears as though the module isn't being maintained anymore.

What is failing? Archive::Tar is a Pure Perl module, AFAIK. It needs no compilation. It just should work.

If there's anything wrong with it, it must be platform specific quirks. No it doesn't look like it's a missing binmode(), there are plenty of those.

I'll try and look into it myself, later today.

  • Comment on Re: Re: Archive::Tar Memory Consumption

Replies are listed 'Best First'.
Re: Re: Re: Archive::Tar Memory Consumption
by agentv (Friar) on Aug 22, 2002 at 12:56 UTC
    ...actually, I think that Archive::Tar is a Pure Perl module, but it uses (though does not depend upon) another module for gzip compression which is binary and requires compilation.

    ...All the world looks like -well- all the world, when your hammer is Perl.
    ---v

      ..actually, I think that Archive::Tar is a Pure Perl module, but it uses (though does not depend upon) another module for gzip compression which is binary and requires compilation.
      Indeed it does: Compress::Zlib. But development of this module is independendent of that of Archive::Tar.

      Comparing Activestate's version with the most recent one on CPAN, you can see that they're both the same version: 1.16. So there's no problem about that.

      Update: Ah, damned: the above URL to Activestate's package again doesn't include a port for Win32. The other, older repository does, but is only at version 1.08.

Re: Re: Re: Archive::Tar Memory Consumption
by bart (Canon) on Aug 24, 2002 at 13:32 UTC
    OK, I've had time to look at it. I found the actual culprit, but at the same time, I found some more errors that affect other platforms as well.

    The reason why it failed, is this snippet, at lines 237-239:

    if ($^O eq "MSWin32") { $fh = $_[0]; }
    where later on, this is done with it:
    $fh = Compress::Zlib::gzdopen_ ($fh, $mode, 0)
    gzdopen_ is a low level function in Compress::Zlib. Well, guess what: this function expect a fileno, not a handle. So this fails. This does _drat() (it should either goto &_drat; or return _drat();, but not just call _drat()). $! is not set, so $error isn't set to a true value, and that's why it fails in such an ungraceful way. But I digress.

    The solution is simple: set

    if ($^O eq "MSWin32") { $fh = fileno($_[0]); }
    instead. And now all tests succeed.

    Here's the whole diff (for Archive-Tar-0.22.tar.gz):

    --- Tar.pm Fri Apr 28 00:50:16 2000 +++ blib/lib/Archive/Tar.pm Sat Aug 24 15:06:04 2002 @@ -79,7 +79,7 @@ my $error; sub _drat { - $error = $! . ''; + $error = $! . '' || 'unknown error'; return; } @@ -235,7 +235,7 @@ or goto &_drat; if ($^O eq "MSWin32") { - $fh = $_[0]; + $fh = fileno($_[0]); } else { $fh = fcntl ($_[0], F_DUPFD, 0) @@ -248,7 +248,7 @@ # $fh = Compress::Zlib::gzopen ($_[0], $mode) # or &_drat; $fh = Compress::Zlib::gzdopen_ ($fh, $mode, 0) - or &_drat; + or goto &_drat; } else { $flags = fcntl ($_[0], F_GETFL, 0) & (O_RDONLY | O_WRONLY | O_RDWR +);

    I'll try to warn the maintainer.