Sat Jun 13 02:59:53 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 22:04:55 2020, SLAFFAN wrote:
> 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.
$ENV{APPDATA} would be better than $ENV{PROGRAMDATA}
It is easy enough to add to mktmpdir.c for Windows builds, so I can work up a
PR if Roderich is in favour of the idea.
