On Thu, Dec 18, 2014 at 10:22 PM, Shawn Laffan <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
