Community
Participate
Working Groups
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
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.
As far as I remember this is the expected behaviour
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.
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.
Assigning to you because I believe this is related to what you are currently looking into.
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 ***
