Did you check if there is a CPAN module for what you want? This is often best remedy against windows idiosyncraties. Did you look at perlmonks.org? I had a quick glimps eand only saw that they were discussing flock on windows.
just two ideas, not really par related, i guess. On Fri, Mar 11, 2011 at 8:03 AM, Travis Williams <[email protected]> wrote: > 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 < > [email protected]> wrote: > >> On Fri, Mar 11, 2011 at 1:53 AM, Travis Williams <[email protected]> >> 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 >> >
