Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 289086

Summary:	[PI] DLLs in temp folder are not replaced when its contents change
Product:	[Eclipse Project] Platform	Reporter:	Silenio Quarti <Silenio_Quarti>
Component:	SWT	Assignee:	Platform-SWT-Inbox <platform-swt-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	ericwill, neale
Version:	3.6	Keywords:	triaged
Target Milestone:	---
Hardware:	PC
OS:	All
Whiteboard:	stalebug

Description Silenio Quarti

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

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

2009-09-11 11:13:38 EDT

Last thing discussed: add a -clean flag that will overwrite any existing libraries.

Comment 3 Silenio Quarti

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

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.