Thank you for the detailed explanation, i have moved over to a pid file that
is named based on a var out of the config file (my program can be running at
multiple times called with different configs) but putting that the cache
area is an interesting thought. I hate coding for windows :( So many
things that I normally do in unix are just useless here.
Travis
On Fri, Mar 11, 2011 at 6:02 AM, Roderich Schupp <
roderich.sch...@googlemail.com> wrote:
> 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
>
