| How to repair corrupted files in the $HOME/.p2 repo? [message #1723905] |
Thu, 18 February 2016 23:09  |
Eclipse User |
|
|
|
For quite a while now, I've been struggling with the side effects of running out of disk space on my Ubuntu VM a couple of weeks ago now. I enlarged the virtual disk relatively quickly, but apparently something I was doing with Eclipse at the time managed to corrupt five jar files in my $HOME/.p2 tree. That's the theory, at least.
Along the way, I battled an Eclipse exception message about a corrupted zip file that was telling me nothing about what zip file was corrupted (which I filed a bug for, which someone happily fixed, in the source at least, in less than an hour after I filed it). It took me embarrassingly much longer than it should have for me to realize I could point a debugger at the target instance to figure out what archive was corrupted.
I determined that there were actually five corrupted jar files, all in my "$HOME/.p2" tree, and these are them:
$HOME/.p2/pool/plugins/org.eclipse.emf.mapping.ecore2ecore.editor_2.7.0.v20160201-0859.jar
$HOME/.p2/pool/plugins/org.eclipse.emf.mapping_2.9.0.v20160201-0859.jar
$HOME/.p2/pool/plugins/org.eclipse.emf.mapping.ecore2xml_2.9.0.v20160201-0859.jar
$HOME/.p2/pool/plugins/org.eclipse.emf.mapping.ecore2xml.ui_2.8.0.v20160201-0859.jar
$HOME/.p2/pool/plugins/org.eclipse.emf.mapping.ui_2.7.0.v20160201-0859.jar
None of these files are zero length, they're just corrupted, as both "jar tvf" and "unzip -tq" tell me.
At this point, I thought I was in the home stretch, because this "$HOME/.p2" thing felt like the "$HOME/.m2/repository" tree, where you can just remove corrupted files and the next Maven build will regenerate them. Unfortunately, this is not the case. Removing any of them just changed the exception message (ironically, now giving me the full path to the jar file that doesn't exist).
So how do I repair this with minimal effort?
|
|
|
|
|
| Re: How to repair corrupted files in the $HOME/.p2 repo? [message #1723912 is a reply to message #1723905] |
Thu, 18 February 2016 23:48  |
| Eclipse User |
|
|
|
Hi David,
With the Eclipse Installer (in advanced mode on the first page; in simple mode via the "Bundle Pools..." menu item) you
can open the Bundle Pool Analysis tool. There you can wait for the damage detection to finish and then either attempt to
repair or delete damaged artifacts. I've attached a screenshot for you. It's kind of an advanced function, so please
make a backup copy of your entire pool before you try to modify it. And please let me know how the procedure worked for
you. Good luck ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 19.02.2016 um 05:09 schrieb David M. Karr:
> For quite a while now, I've been struggling with the side effects of running out of disk space on my Ubuntu VM a
> couple of weeks ago now. I enlarged the virtual disk relatively quickly, but apparently something I was doing with
> Eclipse at the time managed to corrupt five jar files in my $HOME/.p2 tree. That's the theory, at least.
>
> Along the way, I battled an Eclipse exception message about a corrupted zip file that was telling me nothing about
> what zip file was corrupted (which I filed a bug for, which someone happily fixed, in the source at least, in less
> than an hour after I filed it). It took me embarrassingly much longer than it should have for me to realize I could
> point a debugger at the target instance to figure out what archive was corrupted.
>
> I determined that there were actually five corrupted jar files, all in my "$HOME/.p2" tree, and these are them:
> $HOME/.p2/pool/plugins/org.eclipse.emf.mapping.ecore2ecore.editor_2.7.0.v20160201-0859.jar
> $HOME/.p2/pool/plugins/org.eclipse.emf.mapping_2.9.0.v20160201-0859.jar
> $HOME/.p2/pool/plugins/org.eclipse.emf.mapping.ecore2xml_2.9.0.v20160201-0859.jar
> $HOME/.p2/pool/plugins/org.eclipse.emf.mapping.ecore2xml.ui_2.8.0.v20160201-0859.jar
> $HOME/.p2/pool/plugins/org.eclipse.emf.mapping.ui_2.7.0.v20160201-0859.jar
>
> None of these files are zero length, they're just corrupted, as both "jar tvf" and "unzip -tq" tell me.
>
> At this point, I thought I was in the home stretch, because this "$HOME/.p2" thing felt like the
> "$HOME/.m2/repository" tree, where you can just remove corrupted files and the next Maven build will regenerate them.
> Unfortunately, this is not the case. Removing any of them just changed the exception message (ironically, now giving
> me the full path to the jar file that doesn't exist).
>
> So how do I repair this with minimal effort?
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05223 seconds
Home
, you can submit the same answer on my SO posting: