Bug 273127

Comment 1 Henrik Lindberg 2009-04-22 07:13:32 EDT

What is meant by "deal with" in this context? Report the error? Survive the failure? Or "find a way around the lock" ?

afaik, neither delete nor renameTo works when the file is "in use" on Windows. Native code would have to be written to release the file handle. However, If the file is "in use", it can still be opened for writing, so it could be overwritten I guess. But I am not sure what actually happens if you do this on a running exe.

An alternative that may work is to terminate Eclipse in such a way that it delegates to a script that performs the switch once the exe is terminated. Alternativly, if the "overwrite" is a dangerous operation, it may work to do it just before exit.

I understand that there are also cases on all OS when the exe is on readonly media, or user is not authorized to overwrite. 

What does the metadata generated today look like?
What should happen if it is impossible to update the exe?

Comment 2 Henrik Lindberg 2009-04-22 10:20:28 EDT

Here is information from Microsoft regarding rename and delete of files "in use" http://support.microsoft.com/kb/140570

Comment 3 Pascal Rapicault 2009-04-22 23:29:35 EDT

sorry for the lack of precisions. "dealt with" here meant
1) (ideal) we support the update of the exe in case where it is locked 
2) verify that we are not failing the update if the new exe can not be upgraded. 
3) see if we have a workaround in the 3.5 timeframe to deliver the exe (for example running the director app from the command line to do the upgrade).

I also think that #2 also relates to the delete action and how it treats  the inability to complete successfully.

Here is the touchpoint data in the IU toolingorg.eclipse.sdk.ide.launcher.cocoa.macosx.x86 that puts down the executable on a mac
      <touchpointData size='1'>
        <instructions size='2'>
          <instruction key='install'>
            unzip(source:@artifact, target:${installFolder}); chmod(targetDir:${installFolder}/Eclipse.app/Contents/MacOS/, targetFile:eclipse, permissions:755); chmod(targetDir:${installFolder}/Eclipse.app/Contents/MacOS/, targetFile:eclipse.ini, permissions:755);
          </instruction>
          <instruction key='uninstall'>
            cleanupzip(source:@artifact, target:${installFolder});
          </instruction>
        </instructions>
      </touchpointData>

Comment 4 Henrik Lindberg 2009-04-23 07:33:01 EDT

(In reply to comment #3)
> sorry for the lack of precisions. "dealt with" here meant
> 1) (ideal) we support the update of the exe in case where it is locked 
> 2) verify that we are not failing the update if the new exe can not be
> upgraded. 
> 3) see if we have a workaround in the 3.5 timeframe to deliver the exe (for
> example running the director app from the command line to do the upgrade).
>
Comments 
1) I think this only applies to Windows, since a non-writable executable on *nix probably means that the user does not have the permission to write. I think it is appropriate to fail in this case.
2) As you said, this is related to delete, but also how unzip works when there are existing files.

Unfortunately, the problem on Windows is quite horrible. Any file that needs to be deleted/replaced can be locked (the user may be looking at the file with some app). The exe may be in use multiple times. The only sure way to delete/replace files is to use the native Windows (XP and NT at least) call that performs the operation on a reboot of the OS. Hence the typical instructions to users "Terminate all other running applications before proceeding with installation", and "A reboot (of Windows) is required for the changes to take effect". 

Further, all the operations that encounter locked files, must determine if it is really a locked file situation, or if it should fail. The operations must then have a way to defer the operation until later, and actions may need to write temporary files (e.g. one of the files in a zip can't be processed), and apply chmod to the temporary file. A variant of the BackupStore could probably be used to keep the temporary files, and it could be given the possibility to also store anti-matter-files that triggers a delete. It is somewhat problematic to deal with series of actions (e.g. an unzip followed by a chmod), as commands needs to know if they should run on the deferred file or not.

So, during the install, the actions write stuff into the deferred store. On completion, the system needs to exit with delegation to code that is guaranteed to not be replaced in the delegation. This could be done by copying the exe/script to a temp location before running it (to ensure that the script itself can be updated). The script would be given the deferred store location as a parameter and would complete the installation. Ideally the "eclipse runtime" should provide the support for Windows "replace on reboot" thus making it possible for the deferred cleanup to be a normal runtime (although some tricks may be needed when making the "safe copy" that executes it). Alternatively, a separate native exe could be written that performs the cleanup,  or the standard eclipse.exe could be given som parameters to make it perform the cleanup. Yet another (simple) solution is to let the DeferredStore generate a script with a sequence of remove/replace commands (but I don't think there is a standard windows command for "replace on reboot"), but it could at least perform normal delete and replace commands).

I am sure there are additional issues when handing over to the cleanup on exit - making sure that the process really did terminate and that locks where released, as well as making sure that the operations really did replace the files after a reboot (or what to do if "replace on reboot" is not implemented, and the cleanup script fails).
 
I can implement the DeferedStore, but need help with the native windows stuff.

Comment 5 DJ Houghton 2009-04-29 16:22:22 EDT

FYI current behaviour on WinXP is to try and delete the old file first (which silently fails) and then to unzip the new file (which also silently fails). We have been lucky because the Win32 exe doesn't seem to have changed since last July.

Comment 6 Pascal Rapicault 2010-04-19 14:33:06 EDT

Taking that for 3.6 with very low expectations to be able to make it happen.

Comment 7 Eclipse Genie 2019-10-13 14:14:08 EDT

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.

--
The automated Eclipse Genie.