JBIDE-20519 Internal model fails when multiple instances of Studio are opened #442
Conversation
| @@ -103,11 +114,20 @@ public void stop(BundleContext context) throws Exception { | |||
| } | |||
|
|
|||
| private void cleanTempFiles() { | |||
| if(tempFolder != null && tempFolder.exists()) { | |||
| File[] fs = tempFolder.listFiles(); | |||
| cleanEFS_Files(tempFolder, System.currentTimeMillis() - 30l * 24l * 60l * 60l * 1000l); //in global folder remove only files one month old. | |||
There was a problem hiding this comment.
Not sure we actually need any timeout period for temp files. If we move this files from the shared system temp folder to the eclipse workspace then the only one eclipse instance is supposed to work with this worskspace/temp folder at the time. Do we need to store temp files from previous Eclipse sessions?
There was a problem hiding this comment.
We have two different cases for creating temporal files.
One is storing long values of object properties, and sharing by objects that load the same value, here we generate the file name. I moved these files to the eclipse workspace.
Second, is copying jars, object that references the copy is unique, and the name of file is generated by File.createTempFile - which always creates a file in the system temp folder. This method creates a unique name for file and I would not like to change the logic here, reinventing our own generator of file unique names. We do not need to store temp files, but they can be 'stored' by a kill/crash of Eclipse. When Eclipse is closing normally, there is no way to say which 'stored' in temp folder files are used by another running Eclipse instance and which are not.
Timeout for 'very old files' is applied to system temp folder only. Workspace temp folder in the next line is cleaned without any timeouts.
No description provided.