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

Bug 326263

Summary: Windows File Locks are obtained on bundles exporting extension points and not released.
Product: [Eclipse Project] PDE Reporter: Ed Costello <edward.costello>
Component: UIAssignee: Curtis Windatt <curtis.windatt.public>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: ankur_sharma, curtis.windatt.public, darin.eclipse, edward.costello, Olivier_Thomann, simon.lieschke
Version: 3.7Flags: curtis.windatt.public: review? (ankur_sharma)
Target Milestone: 3.6.2   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Reproduction of this Issue none

Description Ed Costello CLA 2010-09-26 16:53:39 EDT 
Build Identifier: 20100617-1415

When a workspace bundle implements an Eclipse Extension Point (plugin.xml) exported by a bundle in the Target Platform, Eclipse obtains a Windows File Lock on the bundle in target platform as part of the build step. There appears to be no-way to release this lock other than closing Eclipse or using an Unlocker program.

These locks cause issues in our development environment where we rebuild our target platform from a central repository. This behavior is only observed on windows, however I believe that to be because file locking is less strict on *nix platforms.

The Locks appear to be obtained as part of the "Plug-in Manifest Builder" and sometimes the "Extension Point Schema Builder" as disabling both these builders prevents the locks being obtained. In most cases (including the attached reproduction) just disabling the "Plug-in Manifest Builder" is sufficient.

These File Locks persist when the Projects implementing the Extension Point are closed and when the target platform is deactivated or deleted in the Eclipse Preferences. There appears to be no way to remove these locks other than closing Eclipse.

Reproducible: Always

Steps to Reproduce:
1. Create a bundle that exposes an Extension Point. This should be a JAR rather than a project or folder. (ExportExtensionPoint.jar servers this purpose in the reproduction, The ExportExtensionPoint eclipse project is the source of this).

2. Create a clean eclipse workspace with no projects in it

3. Add the bundle containing the extension point to the target platform of this workspace.

4. Create or import a Plugin project with an extension implementing the extension point (The UseSimpleExtensionPoint eclipse project serves this purpose in the reproduction)

5. Ensure the "Plug-in Manifest Builder" is enabled on this Plugin Project.

6. Trigger a Clean Build

7. Use http://ccollomb.free.fr/unlocker/ or a similar tool to inspect the bundle from step 1 for file locks, it will show that it's locked by eclipse.
Comment 1 Ed Costello CLA 2010-09-26 16:55:25 EDT 
Created attachment 179592 [details]
Reproduction of this Issue
Comment 2 Curtis Windatt CLA 2010-09-27 16:14:58 EDT 
Confirmed using PDE code from HEAD on linux.  If the plug-in manifest builder has run, there is a lock opened on the bundle in the target.

I couldn't find anything in the builder code that would lock the file.  I expect that buried somewhere in the builder we open the jar to get the schema file.  The schema file would be used to verify the contents of plug-in.xml.  I'll do some more digging.
Comment 3 Curtis Windatt CLA 2010-09-27 16:55:03 EDT 
The file is opened in SchemaUtil.getInputStream(URL).  Darin thinks there may be a known issue with url.openStream().  Olivier, do you happen to know anything about it?

We do use open stream in many places in the platform.
Comment 4 Curtis Windatt CLA 2010-09-28 12:20:29 EDT 
Fixed in HEAD.  Added two addtions:

1) When opening the url connection, if it is a jar file connection setUseCaches is set to false.  This results in the file being closed when the stream is no longer being used.  It also avoids connection issues that others have had.

2) If the connection is a jar file connection, the jar file is obtained an explicitly closed.  In my test cases (1) was enough to close the file, but since the behaviour can change based on the JRE being used, it is better to have the additional check.

I used code from JDT (JavaElement) for reference.

See Schema, SchemaUtil and SchemaTraversePerfTest
Comment 5 Ed Costello CLA 2010-09-28 16:30:42 EDT 
Thanks for the quick resolution, would it be possible to back port this fix to a 3.6 service pack?

This is causing significant pain for our windows based developers and we'd like to take advantage of it without waiting for 3.7.
Comment 6 Curtis Windatt CLA 2010-09-29 10:28:19 EDT 
Reopening to consider for 3.6.2.  I'm on the fence whether this is something we want to backport.  It's not a trivial fix, but it should be safe.
Comment 7 Curtis Windatt CLA 2010-12-10 15:11:03 EST 
I have committed the code to the maintenance branch.

Ankur, please verify.
Comment 8 Curtis Windatt CLA 2011-01-20 15:54:04 EST 
ping Ankur,

Please verify this when going through the 3.6.2 test pass.
Comment 9 Ankur Sharma CLA 2011-01-21 03:03:31 EST 
Verified in M20110112-0800
3.6.2. is not holding file locks