On Fri, Mar 11, 2011 at 1:53 AM, Travis Williams <trav...@gmail.com> wrote:
> This code breaks, remove the flock and everything works great, I'm using the
Uh, it's the flock for sure. Simple test program (no PAR::Packer involved):
use Fcntl ':flock';
use Archive::Zip qw( :ERROR_CODES :CONSTANTS );
# part 1
my $zip = Archive::Zip->new();
$zip->read( 'fubar.zip' ) == AZ_OK or die "read zip: $!";
my $member = $zip->memberNamed("fubar.dll") or die "no member";
# part 2
open SELF, '<', 'fubar.zip' or die "open SELF: $!";
flock SELF, LOCK_EX | LOCK_NB or die "flock SELF: $!";
# part 3
my $filename = "3d2b5e28.dll";
open my $fh, '>', $filename or die "open: $!";
binmode($fh);
$member->extractToFileHandle($fh) == AZ_OK #### croaks
or die "extract: $! ($^E)";
close $fh;
print "extracted!\n";
It blows up in extractToFileHandle :(
Part 1 mimicks what goes on when you run your packed executable:
because of "use" statements (e.g. "use DBI") before your flock,
PAR has already opened the zip file that is your packed executable ($0).
It probably has also called memberNamed (and other) methods from
Archive::Zip. Note that DBD::ODBC has _not_ yet been extracted,
because it isn't mentioned in an explicit "use".
Part 2 is you flocking the zip file.
Part 3 mimcks what happens for "DBI->connect": it parses "dbi:ODBC:..."
and decides to dynamically load DBD::Oracle. This is intercepted by PAR
which locates the ODBC.dll in the zip and then tries to
read and decompress the corresponding bytes from the zip file.
But it is flocked now!
(So the strange IO error we saw is not from the filehandle
where the decompressed bytes should be finally written to, but
from the filehandle used to read the zip file.)
I suggest you use a file other than $0 for flocking, perhaps just create a dummy
file in the cache area (which is $ENV{PAR_TEMP}).
Cheers, Roderich
