Community
Participate
Working Groups
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Build Identifier: 20090920-1017 I have an RCP application with all the p2 trimmings. I build it using a p2 headless build with p2 gathering etc. I added my jre using the root.folder.jre method. The install is fine. However, updates are failing with a java.io.IOException from BackupStore.java:258. It looks like it is trying to delete jre\lib\ext\dnsns.jar after having made a backup. Please see log output below. I tried installing a very recent jre and got the same result. Any ideas for me to try before I open a bug? !ENTRY org.eclipse.equinox.p2.engine 4 4 2009-10-14 21:28:12.116 !MESSAGE An error occurred while uninstalling !SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2009-10-14 21:28:12.116 !MESSAGE session context was:(profile=profile, phase=org.eclipse.equinox.internal.provisional.p2.engine.pha ses.Uninstall, operand=[R]com.bluefire.jre.feature_root 1.0.0.v200910142041 --> null, action=org.eclipse.equinox.internal.p2.touchpoint.natives.ac tions.CleanupzipAction). !SUBENTRY 1 org.eclipse.equinox.p2.touchpoint.natives 4 0 2009-10-14 21:28:12.116 !MESSAGE Backup of file C:\Program Files\bluefireBlaze\jre\lib\ext\dnsns.jar failed. !STACK 0 java.io.IOException: File that was copied to backup could not be deleted: C:\Program Files\bluefireBlaze\jre\lib\ext\dnsns.jar at org.eclipse.equinox.internal.p2.touchpoint.natives.BackupStore.backup(BackupStore.java:258) at org.eclipse.equinox.internal.p2.touchpoint.natives.LazyBackupStore.backup(LazyBackupStore.java:36) at org.eclipse.equinox.internal.p2.touchpoint.natives.actions.C leanupzipAction.cleanupzip(CleanupzipAction.java:86) at org.eclipse.equinox.internal.p2.touchpoint.natives.actions.C leanupzipAction.execute(CleanupzipAction.java:30) at org.eclipse.equinox.internal.p2.engine.ParameterizedProvisio ningAction.execute(ParameterizedProvisioningAction.java:35) at org.eclipse.equinox.internal.provisional.p2.engine.Phase.mai nPerform(Phase.java:129) at org.eclipse.equinox.internal.provisional.p2.engine.Phase.per form(Phase.java:72) at org.eclipse.equinox.internal.provisional.p2.engine.PhaseSet. perform(PhaseSet.java:44) at org.eclipse.equinox.internal.provisional.p2.engine.Engine.pe rform(Engine.java:54) at org.eclipse.equinox.internal.provisional.p2.ui.operations.Pr ovisioningUtil.performProvisioningPlan(ProvisioningUtil.java :389) at org.eclipse.equinox.internal.provisional.p2.ui.operations.Pr ofileModificationOperation.doExecute(ProfileModificationOper ation.java:61) at org.eclipse.equinox.internal.provisional.p2.ui.operations.Pr ovisioningOperation.execute(ProvisioningOperation.java:37) at org.eclipse.equinox.internal.provisional.p2.ui.ProvisioningO perationRunner$1.run(ProvisioningOperationRunner.java:94) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Reproducible: Always Steps to Reproduce: 1. Perform headless pde build 2. Attempt to update 3. Update progresses to 100% before failing to delete a file that was copied to a backu... java.io.IOException in BackupStore.java:258
Created attachment 149659 [details] Message from ui
Created attachment 149661 [details] Error dialog from ui
Here's a topic I created for the same issue... http://www.eclipse.org/forums/index.php?t=msg&th=155992&start=0&S=8f6c8caffbb95c9c3fa6ffa30db16ae7
In general p2 will not be able to upgrade the JRE because it will be locked by the running process. Assuming your JRE is not actually changing each upgrade, you should be able to avoid this by not incrementing the version on that jre feature.
(In reply to comment #4) > In general p2 will not be able to upgrade the JRE because it will be locked by > the running process. Assuming your JRE is not actually changing each upgrade, > you should be able to avoid this by not incrementing the version on that jre > feature. I distribute certificates and a sqlite_jni.dll as part of my jre. With Ganymede 3.4.1 I included a JRE (execution environment) and performed builds using the product export option in the Eclipse IDE. The jre always updated fine with Ganymede exported repository. Never had a problem. Anyway, if we want to add a certificate or a dll or something, this was a great way for me to do it. I'm upgrading our team to Galileo and I'm trying to create an automated build process leveraging pde headless build capabilities (thanks for your post on how to do this). So I just want the Galileo pde headless built repo to be able to do what the Ganymede IDE product export with repo could do. An IOException from the p2.engine on update seems like a bug. I could be wrong, I'm just frustrated.
Henrik, could you please give a hand here?
Note that in Ganymede the update of the JRE would have silently failed to overwrite any files that were locked open but the p2 update itself would proceed. The difference now is that it causes the entire update to fail.
Does not seem to be an issue with the backup store per se - it is actually doing exactly what it is supposed to be doing. However, there is currently no support for asking for a "soft delete" - i.e. ignore errors if it was impossible to delete a file, if that is what should happen in the particular case. The bugger issue is how to update things that are locked on a windows machine. It really requires a shutdown of the application that holds the lock (or even a reboot after first having given windows special instructions to "delete files on startup" - hence the many reboots while installing things on windows). Adding such support requires native code for windows. See comment #7 - what should p2 do? silently ignore the case, or as it does now, by giving up? If it should silently ignore the issue, then the backup store can be given a new method to call, and the locations where this is happening needs to ask for the backup using this method instead of the regular call. Is it possible to know when to ignore such an error?
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. If you have further information on the current state of the bug, please add it. 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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
