Community
Participate
Working Groups
Build id: I20090611-1540 When I start eclipse with the -configuration <config-area> option and the specified directory is read-only or otherwise not usable, I get an exception in the shell (see below), but this exception does not really explain the problem and eclipse even launches, but it is unusable and throws exceptions all over the place. Exception logged on the shell: !MESSAGE Error reading configuration: /local/toni/.eclipse/configuration/org.eclipse.osgi/.manager/.fileTableLock (No such file or directory) !STACK 0 java.io.FileNotFoundException: /local/toni/.eclipse/configuration/org.eclipse.osgi/.manager/.fileTableLock (No such file or directory) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212) at org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio.lock(Locker_JavaNio.java:32) at org.eclipse.osgi.storagemanager.StorageManager.lock(StorageManager.java:388) at org.eclipse.osgi.storagemanager.StorageManager.open(StorageManager.java:686) at org.eclipse.osgi.internal.baseadaptor.BaseStorage.initFileManager(BaseStorage.java:213) at org.eclipse.osgi.internal.baseadaptor.BaseStorage.initialize(BaseStorage.java:147) at org.eclipse.osgi.baseadaptor.BaseAdaptor.initializeStorage(BaseAdaptor.java:121) [...] I suggest to add an early configuration area check to the launcher and clearly identify and report back what's wrong with the location instead of just logging exceptions and keep running.
Created attachment 157612 [details] Proposed fix Attached patch adds a check for the configuration directory for following error conditions: - the directory cannot be created - the directory is not writable - the directory does not support the java.nio file locking method (if no other method is specified) In case of an error, exitcode and exitdata describing the error are reported back to the launcher executable which will show a dialog with the error.
This bug is related to - bug 59780 (improper error reporting when workspace cannot be locked), and - bug 230384 (improper error reporting when parent of config area is not writable, because p2 artifacts are generated in the parent dir) I think that this is an important usability problem to address. End users of our product on top of Eclipse have often run into situations where they accidentally had trouble with file systems being read-only or not lockable, and they could not understand the errors being reported. In fact we have been patching Eclipse in our products in the past to address this, and one motivation for contributing this patch now is that we would prefer consuming an unmodified Eclipse.
Just wondering, when somebody could do an initial triage of this? Attached patch is tested to work fine, and just changes src/org/eclipse/equinox/launcher/Main.java adding error checks and reporting to address important usability concerns.
Also see bug 301431. It should be possible to launch eclipse from a completely read-only configuration by using osgi.configuration.area.readonly property. We should not be checking if we canWrite or if isLockingAllowed if osgi.configuration.area.readonly property is defined. Also the ability to write in the configuration/ folder may not be good enough. There have been several issues reported where the user may have write access to the configuration folder but not necessarily to every sub-folder under the configuration area. This can also cause the IOExceptions when attempting to lock the file configuration/org.eclipse.osgi/.manager/.fileTableLock It is unfortunate that we have to do the nio check this early. I think the fact that we could not open the StorageManager in the framework but we still allow the framework to launch is a bug that we should consider fixing instead of forcing the launcher to attempt a lock.
(In reply to comment #4) > Also see bug 301431. > > It should be possible to launch eclipse from a completely read-only > configuration by using osgi.configuration.area.readonly property. We should > not be checking if we canWrite or if isLockingAllowed if > osgi.configuration.area.readonly property is defined. Sure, we can add that check. > Also the ability to write in the configuration/ folder may not be good enough. > There have been several issues reported where the user may have write access to > the configuration folder but not necessarily to every sub-folder under the > configuration area. This can also cause the IOExceptions when attempting to > lock the file configuration/org.eclipse.osgi/.manager/.fileTableLock I think that's good enough for a basic sanity test. On the other hand, if the framework did handle this case better, the check might be obsolete. > It is unfortunate that we have to do the nio check this early. I think the > fact that we could not open the StorageManager in the framework but we still > allow the framework to launch is a bug that we should consider fixing instead > of forcing the launcher to attempt a lock. I agree, improving the framework is preferable.
(In reply to comment #5) > > It is unfortunate that we have to do the nio check this early. I think the > > fact that we could not open the StorageManager in the framework but we still > > allow the framework to launch is a bug that we should consider fixing instead > > of forcing the launcher to attempt a lock. > > I agree, improving the framework is preferable. I opened bug 303071 to address the failed configuration lock issue. Please remove the lock check in the next patch.
Created attachment 159429 [details] Patch with suggested changes - Added test for property "osgi.configuration.area.readOnly" No check is done if set. - Removed java.nio locking check
I tested the patch and it looks fine. I am not sure about the need or way you add newlines to the message though. Andrew is this needed. Will the text just wrap if we do not put the newlines?
The message box does get automatically wrapped, we think it looks better without the newlines. Also, it is not enough to have the .readonly property defined, it must equal "true". I released a version without the newlines and that uses Boolean.valueOf to check that the property is "true".
Thanks Andrew! That's great. I assume that Anton deserves an iplog+ on the patch, he's a committer on CDT but not on RT or Platform.
Comment on attachment 159429 [details] Patch with suggested changes (In reply to comment #10) > Thanks Andrew! That's great. > I assume that Anton deserves an iplog+ on the patch, he's a committer on CDT > but not on RT or Platform. Sorry, yes it gets a +iplog
*** Bug 287339 has been marked as a duplicate of this bug. ***
