Hi,

here´s my first try ... find the unified diffs for PAR/Heavy.pm and PAR.pm 
attached (diff against the 1.010 subversion trunk).

I have also implemented a function PAR::refresh_file_cache(), which allows 
long-term servers to cope with tmpwatch - if called at least once a day.
This reflects one of my use cases.
The mechanism should also be race condition proof, assuming a weekly cleanup in 
e.g. /tmp . All time values should be adjustable.

Otherwise - tests should exists, but probably mainly on the PAR-Packer side, 
and that one I did not touch yet.

Best regards,

Markus


[Ericsson]<http://www.ericsson.com/>

MARKUS JANSEN Dipl.-Ing.
Aachen Engineering Hub ClearCase/Git Expert
ITTE Hub Services / CM Automation Components
EDD/IFT/E

Ericsson
Ericsson Allee 1
52134, Herzogenrath, Germany
Phone +49 2407 575 5157
Mobile +49 172 2742003
Exchange +49 2407 575 0
Fax +49 2407 575 14721
markus.jan...@ericsson.com
www.ericsson.com

Legal entity: Ericsson GmbH, registered office in Düsseldorf, Germany, Trade 
Register: Amtsgericht Düsseldorf (HRB 33012). Managing Directors: Stefan Koetz 
(Chairman), Cecilia Wachtmeister, Bernd Mellinghaus. Supervisory Board: Valter 
D'Avino (Chairman). This Communication is Confidential. We only send and 
receive email on the basis of the terms set out at 
www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>



From: Philip Kime [mailto:philk...@kime.org.uk]
Sent: Monday, June 22, 2015 3:56 PM
To: Roderich Schupp
Cc: Markus Jansen; Shawn Laffan; par@perl.org
Subject: Re: PAR + tmpwatch = mess

Please break some code - fixing this is the number one request for biber users 
as biber is packed with pp and this issues bites many windows users due to some 
supporting XML  files disappearing from the cache after auto tmp cleanup ...

PK

--
Dr P Kime

On 22 Jun 2015, at 15:44, Roderich Schupp 
<roderich.sch...@gmail.com<mailto:roderich.sch...@gmail.com>> wrote:
On Mon, Jun 22, 2015 at 3:25 PM, Markus Jansen 
<markus.jan...@ericsson.com<mailto:markus.jan...@ericsson.com>> wrote:
My point was simply that the unpacking modification might break some code.

Yes, let's break some code then :)
Cheers, Roderich

Attachment: PAR_canary_01.diff
Description: PAR_canary_01.diff

Reply via email to