Thanks for the clarifications about Archive::Unzip::Burst and the lock
process.
The example I was (unclearly) referring to is one where the PAR packed
script tries to re-access packed files which were purged by a clean-up
while the the PAR process is running. An example from my use-case is
when a now-deleted glade file is re-accessed to initialise some new
widgets, and thus would cause exceptions in the application.
There is nothing PAR can do automatically in this case, and nor should
it. It is best left to any packed script and modules to trigger a
re-extraction, or lock these files in the first place. The developer
packing the script can easily adjust their own code to allow for these
cases, but the addition of such re-extraction to dependencies maintained
by others would be more involved or simply unlikely. Any PAR-automated
approach would be fraught and probably fragile. I think this last point
relates back to your earlier comment about not wanting PAR to override
CORE::open, with which I agree.
Regards,
Shawn.
On 19/12/2014 22:57, Roderich Schupp wrote:
On Thu, Dec 18, 2014 at 10:22 PM, Shawn Laffan
<shawn.laf...@unsw.edu.au <mailto:shawn.laf...@unsw.edu.au>> wrote:
The extractions currently use Archive::Unzip::Burst as the first
attempt. I don't know its behaviour, but I assume that if some
files exist and are locked then it will fail.
It's also protected by the $inc.lock "mutex", just like the slow path
(using Archive::Zip).
In that event the approach switches to iterating over
$zip->memberNames, so it will still work. (Actually,
Archive::Unzip::Burst seems not to install on Windows, so the
latter approach will be the norm on that OS).
Probably very few people use it. It's just a Perl small wrapper around
InfoZip unzip.
Of course, this won't fix the issues where files are cleaned up
while a PAR is running process,
Obviously we will only re-extract *missing* files, so no problem with
locked files here.
so some sort of API sub would still be useful to allow scripts to
re-extract if file opens fail.
That would imply that you are able to know when opening a file from
"deep inside third party modules" fails - how?
WRT the different cache areas, PAR::_extract_inc currently spends
up to 10 seconds trying to create a lock file, so that line needs
to be modified.
Nope. It's not a lock file, it's a lock *directory*. That's because
creation of a directory is the only portable (even network filesystem
safe)
filesystem mutex operation. The up to 10 second delay comes only into
play in the contended case.
Adding a check for -w on the target temp location should be enough
to avoid that when the exe file is in a non-writable directory.
The parent directory of $inc in _extract_inc is writable by
construction.
Cheers, Roderich
