Sat Jun 13 23:32:46 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 Sat Jun 13 18:45:02 2020, SLAFFAN wrote:
> On Sat Jun 13 06:44:03 2020, ralf.neuba...@wido.bv.aok.de wrote:
> > Hi.
> >
> > > > 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.
> > >
> > > $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.
> >
> > What is your concept for getting rid of old PAR_TEMP locations once
> > you get (or create) an updated version of the application or just
> > stop
> > using it? Explicit deinstallation (maybe by using a special argument
> > or variable when calling this version)? An own version of 'delete old
> > files' but with a longer timeout and using a better protocol for
> > detecting the last use and removing only whole directories? Giving
> > the
> > user better hints than cryptic directory names with cryptic files in
> > it, that he can decide which dirs to purge manually? This could be
> > implemented by description files or by a version manager.
> >
> > Explicit deinstallation could be paired with explicit installation --
> > the application only unpacks intelf into a permanent location, if you
> > explicely tell it to do so, in a way every user understands.
> >
> > Mit freundlichen Grüßen
> >
> > Ralf Neubauer
> 
> 
> Currently there is no removal of old PAR archives that I am aware of.
> Removal is left to the user or automated processes.
> 
> It could be done manually using PAR_GLOBAL_CLEAN at the cost of
> running the exe.  e.g. for some_archive.exe this could be packed into
> an uninstall.bat:
> 
> set PAR_GLOBAL_CLEAN=1
> some_archive.exe
> 
> Maybe this could be added to PAR so it does not run the exe and just
> does the cleanup, e.g.:
> 
> some_archive.exe --run-par-cleanup
> 
> It's probably conceptually simpler for the user if it is a separate
> process, though.
> 
> It would also be possible to add that logic to your own perl script so
> it can exit without doing anything, but it might be too late by the
> time that is loaded.

I've run some testing and neither approach works.  When PAR_GLOBAL_TEMP is set 
before running the exe, the archive is unpacked into a different folder named 
like temp-12345 and cleaned up on exit.  Setting it in a BEGIN block within the 
packed script appears too late to have any effect.  Presumably the environment 
is localised or some other flag is set by PAR at startup to check on exit.

It looks like a separate uninstaller is needed, although it would need to 
ensure it does not remove files from under a running process, as otherwise it 
is another example of the original reported issue.

Shawn.

Reply via email to