Community
Participate
Working Groups
Hi! I renamed a JAR file in the local filesystem while eclise was running. Then I realized, that this JAR was used in a Project. Next I could not open the properties of that project to fix the problem but got the error: Unable to create the selected property page. Reasons: Plugin-in org.eclipse.jdt.ui was unable to load class org.eclipse.jdt.internal.ui.preferences.BuildPathsPropertyPage. I tried to refresh and rebuild the project. Then I realized, that I could not even close my eclipse workbench - File>Exit or click on X has no effect. Regards
Can you please attach the full .log file contents.
need to investigate
Created attachment 4131 [details] Log file
>Then I realized, that this JAR was used in a Project. this comment isn't clear, but I suspect that the JAR was used by the running Eclipse. So this has destroyed the installation and there error messages are a consequence of this one. The log shows only errors related to the index store. Moving to platform core to check whether this error condition needs to be handled more gracefully.
Jorg, can you clarify your comment? Did you rename a JAR file that was being used by eclipse, or did you rename a JAR file used by one of the projects in your workspace? If it was an eclipse JAR, which JAR did you rename? Your log file contents seem unrelated to the error you reported creating the property page. Did you start with a fresh workspace after this happened? Were you able to restart with the old workspace? Also, what build of Eclipse were you using?
Regarding the log file. As the reporter indicates the log file was huge and I've only attached the log from the last session.
More comments from the reporter: > Did you rename a JAR file that was being used by eclipse? The JAR file was definetly was only used by a project and not by eclipse. It was in a folder completely outside the eclipse installation folder. > Were you able to restart with the old workspace? Well, when I killed the eclipse process and restarted everything was fine and even the project of call showed up without errors. > Also, what build of Eclipse were you using? Build id: 200302061700 > > If you search for the line > > > > !MESSAGE Plug-in org.eclipse.jdt.ui was unable to load class > > org.eclipse.jdt.internal.ui.preferences.BuildPathsPropertyPage. > > > > you will get to the interesting information for the described problem.
Erich, if you still have the log file, can you attach the section that contains the error that Jorg mentions? The attached log file clearly shows corruption of the HistoryStore, and that we don't recover from that corruption very well. By looking further back in the log I'm hoping to discover the source of the corruption. If you zip the entire log file it might not be too big to attach here.
Created attachment 4231 [details] full log file
It looks like both the history store and the property store are corrupt in this workspace. Furthermore, our attempts to create a new one are failing. Jorg, something severe happened to your metadata directory. Are any of the following possible? - checked your .metadata directory into CVS or otherwise transferred it in a way that could result in file corruption? - the directory containing metadata was on a network drive that was having connectivity problems - out of disk space (or exceeded disk quota) - lost file write permission in the metadata folder When the history store is corrupt, we move the index to a backup location and create a new one. The log files show that we are failing to create a new store. This suggests lack of write access or out of disk space. We should consider a backup backup plan, whereby we avoid using the history store at all if we failed to recreate a new one. Otherwise we're hitting this failure on every file save or copy, resulting in the 3.7MB log file for a single day of work.
Created attachment 4255 [details] borken index store
> It looks like both the history store and the property store are corrupt in > this workspace. Furthermore, our attempts to create a new one are failing. > Jorg, something severe happened to your metadata directory. Are any of the > following possible? > - checked your .metadata directory into CVS or otherwise transferred it in > a way that could result in file corruption? no! > - the directory containing metadata was on a network drive that was having > connectivity problems this might be possible... it is located on a mapped network drive. > - out of disk space (or exceeded disk quota) no! > - lost file write permission in the metadata folder no! > When the history store is corrupt, we move the index to a backup location > and create a new one. The log files show that we are failing to create a > new store. This suggests lack of write access or out of disk space. > We should consider a backup backup plan, whereby we avoid using the > history store at all if we failed to recreate a new one. Otherwise we're > hitting this failure on every file save or copy, resulting in the 3.7MB log > file for a single day of work. Yep, the log is about 80MB now. The history store seems to be a binary file - Now what I actually suppose is that my history store is broken in a way that the method to create a new one failes as well. Maybe have a look for bugs in there. I attatched my index store file. Now after I deleted the file manually the index-store error does not occure in the logfile anymore.
Further investigation is needed to determine: - how you can get into this corrupt state - how to recover correctly Jorg, thanks for giving all the feedback. You can delete that 80MB log file now ;)
*** This bug has been marked as a duplicate of 78099 ***
