Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 262336 - Unzip and Cleanupzip are not robust
Summary: Unzip and Cleanupzip are not robust
Status: RESOLVED DUPLICATE of bug 262333
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: p2 (show other bugs)
Version: 3.5   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: P2 Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-25 22:31 EST by Henrik Lindberg CLA
Modified: 2009-04-20 18:05 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik Lindberg CLA 2009-01-25 22:31:26 EST
UnzipAction:
- The UnzipAction uses FileUtils.unzipFile, which ends up in FileUtils.unzipStream - in this code, if a file being unzipped already exists, it is removed before copied over. The undo of an unzip runs Cleanupzip action and removes the files that were unzipped. There is no backup of overwritten files. Is this intentional?

CleanupzipAction:
- Is used both as an undo of unzip, and as an instruction on its own.
- It removes files and (non empty) directories that were previously unzipped.
- An undo of cleanupzip performs a new unzip. If I understand this correctly this means that the zip file artifact in the artifact repository must still be around - if it is not, then the installation will be corrupted.

To be robust and be able to restore the original state of the installation a backup store is needed - as proposed in bug 262333 so that the unzip can move files out of harms way.
Comment 1 Simon Kaegi CLA 2009-01-25 22:47:25 EST
re: There is no backup of overwritten
files. Is this intentional?

Intentional is not the right word here but indeed it is a known problem. We're vulnerable in the case where the original artifact is not around and perhaps a few other subtle cases. What you propose sounds good.

Comment 2 Henrik Lindberg CLA 2009-01-29 16:36:57 EST
The possible loss of files on use of Unzip/Cleanupzip actions has been corrected in the patch attached to bug 262333. 

The issue with original zip file having to be available for undo of Cleanupzip is not in the above mentioned patch,. 
Comment 3 Henrik Lindberg CLA 2009-04-13 09:15:36 EDT
This issue can be closed as a duplicate of bug 262333 if the remaining issue is deemed to be "by design".
The remaining issue is that if an uninstall fails, and the original zip file is not around in the artifact repository, undo of the cleanupzip will fail.

Is this a possible scenario at all? An artifact repository is modified (the zip file is no longer in the repo), and the changes are mirrored to the user. The user wants to uninstall the thing that was removed. The uninstall fails for some reason. The user would like to get back to exactly the same state as before the uninstall. Is there some mechanism that safeguards the zip file as being "in use" so that it does not disappear?
Comment 4 John Arthorne CLA 2009-04-13 09:46:38 EDT
I think we don't support this in general. If you try to undo an uninstall, and there is no longer any repository containing the metadata and/or artifacts that were uninstalled, the user is likely out of luck (unless by luck the local garbage collector has not yet run). The same limitation exists for revert.
Comment 5 Henrik Lindberg CLA 2009-04-20 18:05:36 EDT
As the remaining robustness issue is "by design" - I am marking this as a duplicate of Bug 262333 since it contains the fix regarding backup.

*** This bug has been marked as a duplicate of bug 262333 ***