Bug 289086 - [PI] DLLs in temp folder are not replaced when its contents change
Summary: [PI] DLLs in temp folder are not replaced when its contents change
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.6   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-SWT-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2009-09-10 11:04 EDT by Silenio Quarti CLA
Modified: 2020-05-04 02:27 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Silenio Quarti CLA 2009-09-10 11:04:32 EDT
When running SWT standalone, if the DLLs are not found and if they exists in the SWT jar. The libraries are extracted into the temp folder and then loaded. If a version of the file already exists in the temp folder, that version is loaded even though the new DLLs from the jar have different (newer) contents.

This is a problem that shows up at nightly builds only (developement time as well). It does not happen with integration builds because the DLL filename changes. But it does cause a lot of confusion.
Comment 1 Neale Upstone CLA 2009-09-11 06:01:37 EDT
Good plan.  Anything done before mid-Oct, I'll have time to test, and most likely adopt at the next milestone release.
Comment 2 Bogdan Gheorghe CLA 2009-09-11 11:13:38 EDT
Last thing discussed: add a -clean flag that will overwrite any existing libraries.
Comment 3 Silenio Quarti CLA 2009-09-11 12:06:09 EDT
I have not find a easy, inexpensive and reliable way of detecting the library in the jar is different than the one in the temp directory. One option was to compare the size of the library, but when the modification is small (add 1 native for example), the library size may not change due to padding.

Checking timestamps is not possible because the library on the jar is found with getResourceAsStream().

Comparing each byte is slow. We may as well extract the library on every launch. I do not think this worth, given that the problem only happens on nightly/custom builds.

The -clean flag (-Dswt.library.clean) is a possibility. If someone suspects that the libraries are stale, it would be possible to specify this flag to force the libraries to be extracted.
Comment 4 Eclipse Genie CLA 2020-05-04 02:27:34 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.