Community
Participate
Working Groups
This is an enhancement to improve the handling of a problem described in bug 44735 and duplicated many times. There are other ways to reproduce this problem, but here's mine: 1. Install Suse SLES 9 beta 3 out-of-the-box. 2. Set up as NFS client so that you can access your NFS-mounted home dir. Unfortunately, statd process isn't running on your Linux NFS client, but you didn't know to check. Other apps seem to work OK. 3. Install Eclipse in your home dir. 4. Run Eclipse. You get some kind of error message preventing Eclipse from starting up. 5. Throw Eclipse away; use Emacs instead. From bug 44735 comment 39: >Marking as wontfix since there isn't anything that we can do. > >Some file-systems and VMs just won't let us do locking properly. (for instance >the HP-UX case) > >People who are having problems with a "non-standard" file-system and locking >should ensure that no other users are currently running that workspace and then >run with the System property to bypass the locking mechanism. > >Will add to README. Judging from the number of times people are running into this (and judging from the number of ways in particular a Linux-for-the-masses box may be configured) I wonder if the README and the command-line switch is the right approach. Furthermore, we can remind the user to read the README before calling the support hotline. Does something like the following work? 1. Catch the condition where lock is failing (Ideally separate that from the condition where the lock mechanism works but the workspace is actually locked. I have merged the two conditions below.) 2. Pop up a dialog: The specified workspace is in use or cannot be locked. [Choose another workspace (default)] [Unlock] [Disable Lock] 3. If the user clicks on "Unlock", try to manually remove the lockfile, then retry locking it. If this fails, return to #2. 4. If the user clicks on "Disable Lock", they get a confirmation dialog: "Are you sure? Locking the workspace is recommended in environments that support it, and you may be able to reconfigure your environment. Click Exit and review the README for advice on enabling locks in your environment." [OK] [Exit (the default)] 5. If the user clicks on "OK", Eclipse behaves as if the "ignoreLockFile" arg was specified.
This will require coordination between the Core and UI teams. Adding NE to CC for comment since the UI does the "startup dialogs and error dialogs work". Adding JM to CC because I know he likes to get lots of email.
Adding Andrew since he's doing the real work here.
We could consider using the osgi.locking system property in the config.ini. In environments where java.nio locking does not work, set it to java.io. If you actually don't want any locking set it "none" and no locking will be done. I'm not sure you will actually be able unlock something that is locked by someone else in general. If it is just a tag file, sure you might be able to delete it but if the originator is using nio, it is unlikely to work.
The file locking issue has bitten quite a few people at my institute. These people do not use eclipse because of the problem during startup. The problem has increased as not only the workspace is being locked but also the configuration (which, for a shared installation, resides in the .eclipse directory in the NFS mounted home-directories; thus moving the workspace to a local filesystem, like tmp, does not work anymore and osgi.locking has to be set to java.io). Of course, when I get to know their problems I tell them how to use eclipse with the osgi.locking=java.io setting. I wonder if it would not be possible to write some code detecting the locking behaviour of the file system and then choosing the appropriate locking strategy automatically. For example, first create a new file in the workspace location and then try to lock it. If acquiring the lock fails then locking using java.nio is broken and should be set automatically (or maybe after notifying the user) to java.io or none. Judging on how often a duplicate of bug 4475 is filed, a lot of people seem to have this problem. And I would guess that the number of people not filing a bug report but just being annoyed by seeing "workspace in use, choose a different one" for no apparent reason is larger.
"And I would guess that the number of people not filing a bug report but just being annoyed by seeing "workspace in use, choose a different one" for no apparent reason is larger." The error message produced by UI is misleading (see bug 67053), and causes a lot of confusion. When an IOException happens during Location.lock, the original message should be presented instead. The error message produced by the framework when Location.lock() fails because nio is not working is: "An error occurred while locking file <file>: <original IOException message>. A probably reason is that the file system or Runtime Environment does not support file locking. You may want to choose a different location, or disable file locking (using the osgi.locking property), but this can cause data corruption." Another problem is that we didn't document the osgi.locking property for 3.0, and this is handled by bug 77112.
Rafael, what do you suggest we do here? I'm not exactly sure what you're saying.
My comments were in response to the last paragraph in comment 4, what has already been addressed by bug 67053. The original issue is basically about: if locking fails with IOException, and the current locking mechanism is java.nio, show a dialog to the user saying: "a locking failure happened, do you want to continue without locking?" This would also require Core to allow changing the locking method on-the-fly.
Created attachment 38396 [details] patch for better user experience This patch adds a check to the IDEApplication. The output of this "lock-check" is used to prompt the user if no locking is possible asking him whether locking shall be disabled and the workspace be fired up anyway...
We sometimes see Fedora users with this problem. Can the better UI experience patch be applied?
but of course, Andrew. Will take a look at the patch and if it plays well, we will have one of the Platform/UI committers release it.
(In reply to comment #10) > Will take a look at the patch and if it plays well, we will have one of the > Platform/UI committers release it. Thanks, Wassim. You, as usual, rock :)
Created attachment 55087 [details] patch against the latest from HEAD, but still a bad solution and I do not endorse it In our ongoing effort to keep our RedHat friends happy, I took the 'better user experience' patch in comment 8 on a test drive. Unfortunately, it fails on a very basic scenario: 1. Launch a runtime workbench. Keep the runtime instance (#1) up. 2. Try to launch a second runtime instance on the same workspace as instance #1 Expected result and the result that you see without the patch: you get a message telling you the workspace is currently in use by another Eclipse application. Great and accurate assessment. Observed result with the patch: You get a message telling you that "the workspace is on a file system which does not support file locking. Do you want to open the workspace without locking? Please note that opening the same workspace a second time might cause data corruption and data loss. Open Workspace?" The assessment of the problem is way off. I also found the message to be a bit scary, but maybe it's just me. I have been a little skittish all day today :) The patch did not apply cleanly to the latest ui.ide plug-in from head. That's expected after a few months, so I am attaching an updated version of the same patch that would be a better point for the next revision.
Created attachment 55130 [details] Rebased to 3.0.0 and changed according to Wassims feedback This version will fix the problem with the misleading message. The check for a lockable workspace is now performed via a temporary file that is deleted right after the test, not via the .lock file itself.
(In reply to comment #13) > Created an attachment (id=55130) [details] > Rebased to 3.0.0 and changed according to Wassims feedback > > This version will fix the problem with the misleading message. The check for a > lockable workspace is now performed via a temporary file that is deleted right > after the test, not via the .lock file itself. > Sorry, should read: "Rebased to 3.3.0 M3,5 (as of 20061206)". Thanks for the feedback, hope this patch passes the tests :)
Boris, can you please take it from here?
Sorry, this bug must have fallen off my radar. Marking for 3.4.
*** Bug 141588 has been marked as a duplicate of this bug. ***
Mass update - removing 3.4 target. This was one of the bugs I marked for investigation (and potential fixing) in 3.4 but I ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
While attached patch addresses the problems found when Java nio locking is not available for the Workspace, this is only part of the story - the Summary should perhaps be changed to "[IDE] Improve handling of workspace locking" Our patch on bug 301226 should also be considered for addressing the case where the configuration area cannot be created on a read-only folder or cannot be locked with Java nio locking. Addressing these two bugs could potentially allow removing the sections about osgi.locking on linux-gtk-ppc from the Eclipse README.
Note that the actual locking method of Locker_JavaNio has changed since the patch was created. Instead of lock = stream.getChannel().tryLock(); it should be lock = stream.getChannel().tryLock(0, 1, false); See also http://bugs.sun.com/view_bug.do?bug_id=6628575 and bug 44735
AFAIK we use this NIO file system access to release the log. Please reopen if you plan to improve this handling.
