Hi [email protected], many users have experienced that with every new version of a PAR application, a new cache directory is created because the MD5 sum of the executable changes.
This can become a problem if there are many users and/or a quick release cycle, so /tmp fills up quickly. My sys-admin is putting the thumb screws on me for that at the moment. ;) Scott Stanton's recent proposal to load .pm module files from memory instead of disk would improve this somewhat, but dll's/so's still need to be extracted and possibly cached. It's currently possible to specify the name of the cache directory as an option to "pp". This then replaces the MD5 sum. However, I would expect that using this feature means that subsequent versions of an application can use the same cache, but won't overwrite it when the executed version changes. Basically, this makes me wonder about the use case of the pp switch which sets the name of the cache directory. For the case where the cache directory name has been set by the user, my proposal for a partial solution would be to write the MD5 sum* of the application that wrote the cache to a file in the cache directory such as "/tmp/par-$USER/cache-somename/app.md5". Then, when an application which uses the same cache directory is started, it can use that md5 to determine whether the cache needs updating. The downside is that this eliminates caching altogether for applications which use the same cache but which are known to be compatible. The upside is that it would be possible to reuse the cache in case of application upgrades without leaving zombie cache directories on /tmp. Another downside is that if two applications using a common cache are run simultaneously, the one started later will try to clobber the cache of the one run earlier. But that problem should manifest right now as well, except it's backwards. So my questions are: - Is anybody using the -T (or --tempcache) option to pp to manually set the cache directory name? - Why are you doing it? - Would this proposal break your code? - Should this be the default when -T is in effect or add yet another flag to pp? - Is this necessary in view of Scott's experimental changes? (I.e. should we then use --clean instead?) - Is there something else I overlooked? - Do I make sense at all? ;) Best regards, Steffen * In case the MD5 sum of the binary is not readily available at the correct state of the execution, i.e. before unpacking, one could add an extra option to pp in which the user can specify a version tag or similar. But that's a fallback solution only.
