Bug #132811 for PAR-Packer: Win32: Crash a week after start

> Hi, > > I just found out why PAR::Packer-generated executables tend to crash > when I interact with them after I started them some days ago and they > stayed mostly idle in the task bar -- this also happened on Win7, but > I analyzed it under Win10: > > https://support.microsoft.com/en-us/help/4506040/temp-folder-with- > logon-session-id-is-deleted-unexpectedly > > You can imagine a program behaving strange or crashing when it wants > to load modules, resources or data files from its PAR_TEMP directory, > but everything but the already open DLLs has vanished. I don't know > exactly which windows versions are affected, but I don't want to give > programs to users that suddenly crash out of nowhere, they might lose > trust into the programs. > > I don't know if there can be a better solution than documenting this > behaviour. Of course one can set PAR_GLOBAL_TEMP or PAR_GLOBAL_TMPDIR, > but you have to use wrapper scripts or an installer that find a > suitable directory on the user's machine and set the variables for the > process or globally -- which a bit defeats the 'one executable, no > installer, just double-click the file I gave you' purpose of > PAR::Packer. So the workaround I found is (without the Win32API::File- > doesn't-exist-on-non-Win32 handling): > > if ('CODE' eq ref $INC[-1] && $^O eq 'MSWin32' && > !$ENV{PAR_GLOBAL_TEMP} && !$ENV{PAR_GLOBAL_TMPDIR}) { > use File::Find; > use Win32API::File qw(:ALL); > #use threads; > #(async > { > no warnings 'File::Find'; > find +{ > no_chdir => 1, > wanted => sub { > # ignore result, handle stays open until program > terminates > -f and createFile $_, 'r ke', 'rw'; > }, > }, $ENV{PAR_TEMP}; > } > #)->detach; > } > > Is there a better way? > > Mit freundlichen Grüßen > Ralf

> This is related to https://rt.cpan.org/Public/Bug/Display.html?id=101800

> On Fri Jun 12 21:35:12 2020, Ralf.Neubauer@wido.bv.aok.de wrote: > > 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.

> Hi. > > > 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

> $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.

-----Original Message----- From: Roderich Schupp via RT <bug-PAR-Packer@rt.cpan.org> 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. 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 current 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