| Summary: | [native] Support for dealing with locked file on windows | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Matthew Trees <matthew_a_trees> | ||||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | aniefer, pascal | ||||||
| Version: | 3.5 | Keywords: | helpwanted | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
|
Description
Matthew Trees
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. |