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

Bug 345770

Summary:	[dropins][shared] Updated version of plugins didn't get loaded when start as non-admin when dropin directory readonly
Product:	[Eclipse Project] Equinox	Reporter:	Allen Zhou <allenwz>
Component:	p2	Assignee:	Krzysztof Daniel <krzysztof.daniel>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	dave, john.arthorne, pascal.rapicault, pascal, pwebster
Version:	3.6.2
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Allen Zhou

2011-05-13 14:52:27 EDT

Build Identifier: 3.6.2

Build Identifier: Eclipse 3.6.2

Reproduced on Windows xp, Windows 7 

Reproducible: Always

Steps to Reproduce:
1. Add  updated version of existing plugins to the dropin directory
2. Make the dropin directory read-only for non-admin
3. Start eclipse as non-admin

Result: Plugins added are not loaded
Expected: Plugins are loaded

If you launch Eclipse using admin before making the directory as read-only, you
will not see the problem.

Reproducible: Always

Steps to Reproduce:
1.Add  updated version of existing plugins to the dropin directory

2.Make the dropin directory read-only for non-admin

3.Start eclipse as non-admin

Comment 1 John Arthorne

2011-05-13 15:14:28 EDT

Is it just the dropins folder marked read-only, or the entire install directory? 

In a read-only install, I believe it is expected that users only see bundles from the shared location that were installed by the administrator. Each user has a private dropin location for software privately installed by a single user.

Comment 2 Pascal Rapicault

2011-05-17 19:20:24 EDT

As far as I remember this is the expected behaviour

Comment 3 DJ Houghton

2011-06-03 15:42:27 EDT

Pascal and I talked about this. The patches will not apply when installed via the dropins or through the UI. This is due to the container IU that we use to represent everything installed in the profile.

Comment 4 DJ Houghton

2012-01-11 16:38:14 EST

I have attached some notes from Pascal to the bottom of this comment. My initial tests at doing this work-around were unsuccessful. Note that these comment only address a work-around, and not whether or not the issue is something that can be changed going forward. 

--- 

For the pb about the patch not applying in shared install, if this is a blocker, I thought about a trick that could get you going.

By defaults patches only apply to a particular IU (this is based on the concept of applicability scope), however it is possible to get patches to apply to multiple IUs (not only ranges but also different ids) and even to any IU.

So for the patches to apply, it should be sufficient to have the patch declare that it applies to any IU. From a cursory look at the code I think PatchTest7 and PatchTest7b should cover that case.

Comment 5 Pascal Rapicault

2013-01-23 17:28:39 EST

Assigning to you because I believe this is related to what you are currently looking into.

Comment 6 Krzysztof Daniel

2013-01-24 04:45:14 EST

This issue has nothing to do with the dropins itself. Current shared configuration logic does not allow for a scenario where a user configuration does not contain all master configuration bundles. This is going to be changed soon, but even then it could be only possible to install proper feature patches.

*** This bug has been marked as a duplicate of bug 395516 ***