[FIXED] AppletLoader temp directory

[bobjob]

I have been going through the System properties, and it got me thinking about how the appletLoader handles temporary files.

Currently the applet loader uses "java.io.tmpdir". This works fine for Windows, as the temporary folder is alot more persistent, but on Mac it is cleared each time you restart the computer.

So I was thinking it might be better to use either:
"deployment.user.tmp"
or
check if "deployment.cache.enabled" is true
and check if "deployment.cache.max.size" < 0
then use "deployement.user.cachedir"
and fall back on "java.io.tmpdir".

at least in the case of Mac, Im not sure how linux handles temporary files. It gets annoying having to reload a complete package each time you restart, or log off and change user.

[bobjob]

I cant find anything on the net, about marking files as java cache, or temp.
Would anyone know a better way of handling this.

For now on Mac Ill just use the "user.home" path, and add an uninstall option.

[broumbroum]

Hi! I'm publishing applet on all 3 platforms win,mac and linux, and my java api is writing and reading from java.io.tmpdir as it runs. (I don't use AppletLoader, though)
But you're right, tmpdir should stay not persistent. Since I had to deal on my own with loading native libraries and such, java.library.path tells that user.home is valid on every platform so :

.jar -extract-> natives to user.home -loadnative-> run the applet.

I've got an extension handler as well (this is for browser plugin v.1 only):

.jar -copy-> ext.dirs-> run the applet (mac needs reboot of the browser).
on exit -ensure backup-> jars into user.home/.mystoredir/ -delete-> my ext.dirs .jars -delete-> tmp.files

[bobjob]

.jar -copy-> ext.dirs-> run the applet (mac needs reboot of the browser).
on exit -ensure backup-> jars into user.home/.mystoredir/ -delete-> my ext.dirs .jars -delete-> tmp.files

Its not easy to access the extension dir with Windows.
If your running Windows 7 you need admin permission to put files into program files (were java is located) also once the .jar is loaded into the classpath its not possible to delete it, deleteOnExit doesnt even work. I havnt tested this with a custom classLoader.

[broumbroum]

windows does have r/w exts.dir disabled, unless you run safari for windows which loads extensions .jar from a r/w folder located in the "virtual store" :

USERHOMEDIRECTORY + File.separator + "AppData\\Local\\VirtualStore\\Program Files\\Java\\" + dir + "\\lib\\ext"

where dir = "jre6" or *jre7" resp. for java 6 and 7.

Anyway, with the Java 6 plugin 2, all applets could be using the WebStart deployment back-end without much code effort (then extensions directories become useless). As of the new plugin, applet tags may refer to the jnlp meta files to retrieve .jar resources natively.

[Matzon]

please! do not install into the ext dir! it can cause problems for everyone else.

[kappa]

"java.io.tmpdir" works really well on linux and windows, especially as it doesn't run into any permissions issues (like scary dialogs and access denied) and is nicely hidden as not to alert (scare) users that suddenly strange files are appearing on their computer (System.getProperty("user.home") is too obvious on windows). This should remain as is IMO.

As I understand it the issue here is mac only in that the temp directory is cleared on restart (was not aware of this). As a solution we can simply check if the appletloader is running on mac and then use a hidden directory location for the cache.

I propose

System.getProperty("user.home") + /.lwjglcache

What do you ppl think? (do note I don't have access to mac, so do point out if there's any issue with this solution especially relating to permissions or being too obvious to end users).

please! do not install into the ext dir! it can cause problems for everyone else.

agreed, please do not ever do this, this can cause tons of frustration for application totally unrelated to yours.

[ruben01]

On linux "java.io.tmpdir" is /tmp which is also cleaned on every restart so using that as the cache on linux is also a problem.

[kappa]

On linux "java.io.tmpdir" is /tmp which is also cleaned on every restart so using that as the cache on linux is also a problem.

that's strange, i've used quiet a few distro's but not seen that folder being cleared on restart.

[ruben01]

at least on ubuntu by default /tmp is deleted on reboot

it is controlled by the value of the TMPTIME variable in the '/etc/defaults/rcS' file
being 0 delete on reboot, -1 never delete and other values the number of days to keep the files

I am not sure if the other distros use the same config, and what the default values are.

[kappa]

ok so latest proposal

use the following on all platforms except windows

System.getProperty("user.home") + /.lwjglcache

on windows use we continue using

System.getProperty("java.io.tmpdir")

comments ?

[bobjob]

sounds good.

but should it be in a hidden directory?
I assume LWJGL applets are only going to get bigger an bigger.
people will also want to package runtime downloaded resources into the same folder for neatness (Id like to think so anyway).

anyway something to consider

[ryanm]

but should it be in a hidden directory?

Yes. A million times yes.

[kappa]

people will also want to package runtime downloaded resources into the same folder for neatness (Id like to think so anyway).

anyway something to consider

agreed it would be neater, but think it should be discouraged, just like its not recommended that you store stuff like your java game data in the same location as your java web start cache. e.g. the inner workings of how the appletloader saves/stores files might need to be changed in the future for some reason (it is gonna be changed for above issue), this could break stuff and cause various conflict with same named files, etc.

Secondly people using a mix of unsigned jar and lwjgl certificate jars, don't need any access to the file system. If you do have signed permission, its pretty trivial to just create your own local storage folder and even put files yourself in the same folder as the lwjgl cache folder if you really need.

[kappa]

Push for the lwjgl 2.6 is getting close, want to sort this issue out before the release.

so the current plan is to store the cache files on windows

System.getProperty("java.io.tmpdir")

and on everything else in

System.getProperty("user.home") + /.lwjglcache

however still feels a bit unclean and too visible to store a lwjgl cache folder in the user.home directory.

What would be the opinion to store it in

System.getProperty("user.home") + /.java/lwjglcache

I know that it would look and work pretty well on linux and at the same time tuck away the lwjgl cache files nicely and neatly in user java directory (also where java stores its cache files, so would be ideal). Is it the same situation on mac's too?