Sun Jun 14 16:21:45 2020: Request 132811 was acted upon.
Transaction: Correspondence added by ralf.neuba...@wido.bv.aok.de
Queue: PAR-Packer
Subject: RE: [rt.cpan.org #132811] 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 >
Hi,
-----Original Message-----
From: Roderich Schupp via RT <bug-par-pac...@rt.cpan.org>
>
> On 2020-06-13 06:44:03, ralf.neuba...@wido.bv.aok.de wrote:
> > 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?
>
> There is none.
This question was meant to be an answer to Shawns ideas. He devised
de-facto-installation and I wanted to hear the fully thought out story from him.
If the files are in %TEMP% someday someone will come along and clean up,
because it is a known place for cleaning up potential. No one will look into
Appdata/pp if the disk fills up.
> > Explicit deinstallation (maybe by using a special argument
> > or variable when calling this version)?
>
> Nope. PAR::Packer is expressly designed to work WITHOUT installation and
> tacking on stuff
> is out of the question - there are already too many special
> arguments/variables.
> If you want installation/deinstallation look somewhere else.
Unpacking into something else than %TEMP% is de facto installation. I don't
want installation, but if the archive de facto installs itself into a hidden
permanent directory, there should be some help for the user to keep the space
usage under control. Sometimes I create new versions every couple of days and
if people run that, their disks will fill up. Completely ignoring the problem
means the deinstallation process is to manually clean the correct ones of a big
collections of directories with cryptic names from a not-so-well-know
subdirectory of Appdata. I read most of the source of the package and still
hope there can be some middle ground to make it a bit easier for the users. One
of my suggestions was to at least describe the contents of the directories, for
every cache-xyz/ there could be a cache-xyz-description.txt which lists the
name of the application, the date of unpacking. And maybe the timestamp of
cache-xyz/ and cache-xyz-description.txt should be set to the curr
ent time every time the application is started, that would make it possible to
find the old unused entries with a sorted directory listing.
As an alternative to Shawns solution you could also unpack into %TEMP% like
before, but set a timestamp some interval (e.g. 6 months) in the future for all
files every time the application starts, that would most likely also protect
the files.
Mit freundlichen Grüßen
Ralf
