Fri Jun 12 22:04:55 2020: Request 132811 was acted upon.
Transaction: Correspondence added by SLAFFAN
       Queue: PAR-Packer
     Subject: Win32: Crash a week after start
   Broken in: (no value)
    Severity: (no value)
       Owner: Nobody
  Requestors: ralf.neuba...@wido.bv.aok.de
      Status: open
 Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132811 >


On Fri Jun 12 21:35:12 2020, ralf.neuba...@wido.bv.aok.de wrote:
> Hi.
> 
> > This is related to
> > https://rt.cpan.org/Public/Bug/Display.html?id=101800
> 
> Yes and no. _CANARY_.txt exists and the directory will be repopulated
> on the next start of the program, so there is no problem except having
> to unpack the files again between runs of the program. My problem on
> the other hand is, that I start the program and the files are deleted
> while it is running. My crude protection scheme (locking all of the
> files -- 3500 files in my case, which only works with Windows file
> handles since Perl only gets the 2048 file handles implemented by the
> Windows libc) only protects the files while the program is running, so
> _CANARY_.txt is still needed (and there is a short time window at the
> start of the program, inbetween starting the unpacking and locking the
> files, where files could still vanish if you are unlucky enough to
> have cleanmgr.exe run at exactly the same time.
> 
> Using a non-temp-directory would solve both problems but carries some
> problems on its own, see original message. Declaring %TEMP% to be a
> non-temp directory sounds strange. Raising the existence interval only
> makes it less bad, but doesn't solve it. Also you have to have
> administrator privilege for both.
> 
> I also thought about keeping the files fresh by manipulating their
> timestamps, that also doesn't really solve it, but reflects the truth
> that the files have been used very recently. The would be easy but
> time-consuming on startup (and make _CANARY_.txt obsolete). To solve
> the runtime problems you would have to spawn a parallel job to keep
> the files fresh every couple of hours.
> 
> In essence, the reason is the same, but I don't see a simultaneous
> solution for both aspects that doesn't require user oder administrator
> input.
> 
> Mit freundlichen Grüßen
> 
> Ralf

Yes, the canary file only helps in cases where files are deleted between 
program runs or where files only need to be read at startup.  

The regular temp file cleanup will also impact all users in that the PAR 
archive needs to be unpacked each time it is cleaned up, causing a slow user 
experience for large archives at startup.

FWIW, I'd be OK if the default PAR_TEMP location was in the user's home dir or 
under C:\ProgramData ($ENV{PROGRAMDATA}).  The latter might have issues on 
shared machines depending on how the unpacked files are used, though.

Shawn.

Reply via email to