This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
No more than one copy of NB should be permitted to use the same userdir at once. Compare e.g. Mozilla's ~/.mozilla/jbrown/sas74gs6/lock Should halt you with a dialog if you attempt to use a locked user dir, and give you an option to forcibly override the lock if you are sure it is stale (left by a killed process). Can use Runtime.shutdownHooks to clean up locks when exiting, or launcher can do this and use trap EXIT "rm -f $lock".
Probably requested by ARC.
*** Issue 32083 has been marked as a duplicate of this issue. ***
You can use File.deleteOnExit to clean the lock. Moreover the file could contain a number of port on which the first NetBeans are listening and use it to communicate any commands (move main window to front, open command) to it or check whether the IDE is still running or not.
Re. use of a port - possible security issues here. Not sure if the platform should be opening a port, even when only localhost can connect. First priority is just to mark the directory as being in use.
First priority is clear. Still have to add to "security issue" - one can write a (RSA ;-) key into the lock file and require that key on the connection. That is secure enough.
But Java provides no way to chmod go-r the lock file.
Though I guess the launcher could do e.g. lockdir="$userdir/locks" if [ \! -d "$lockdir" ] then mkdir "$lockdir" chmod go-rwx "$lockdir" fi and Java code would create the actual lock file, containing (1) a large random integer, (2) a free TCP port. Then you need a socket protocol - maybe something like RMI (simply: send the key then a serialized Runnable). Pretty complicated though; I am not sure how important this really is as a feature. "runide.sh -open $file" already opens it in an existing IDE instance if possible. We could make that more general and secure enough to turn on by default on Unix, perhaps.
Some kind of proposal available at http://openide.netbeans.org/proposals/arch/cli.html
Created branch lock_userdir_32054 rooted at BLD200306030100 for core module. Use cd core cvs upd -r lock_userdir_32054 to get it. Contains support for locking user directory plus basic support for communication with running NetBeans via sockets.
Working on this, along with issue #31396. Marking FEATURE due to presence of new API (CLIHandler) and associated capability.
Implemented, with some improvements: - user dir lock done with SecureRandom - WHEN_INIT handlers done late in startup (after main window shown), not during boot - handlers null out args they recognize, and unrecognized args are treated as errors - usage information is extensible 1.72 core/build.xml 1.27 core/manifest.mf 1.11 core/arch/arch-core-launcher.xml 1.2 core/bootstrap/src/org/netbeans/CLIHandler.java 1.13 core/bootstrap/src/org/netbeans/Main.java 1.2 core/src/META-INF/services/org.netbeans.CLIHandler 1.371 core/src/org/netbeans/core/Bundle.properties 1.2 core/src/org/netbeans/core/CLIOptions.java 1.171 core/src/org/netbeans/core/Main.java 1.100 core/src/org/netbeans/core/NonGui.java 1.18 core/src/org/netbeans/core/NonGuiMain.java 1.47 core/test/cfg-unit.xml 1.2 core/test/unit/src/org/netbeans/CLIHandlerTest.java
Sorry to reopen but we require this in the release35R branch (Rainier) for our ARC case (we cannot release without this problem fixed).
OK, but it's still FIXED in 4.0 - keeping RAINIER keyword since milestone is not yet promo-A. Note that this is a somewhat complex change, not a simple patch. Do you also need #31396 (OpenFile usage of this feature)? If so, please mark that RAINIER as well and add a note here. Yarda, do you have any time to try to merge this to release35R? Besides the patched classes listed here, I recall that there were several other critical fixes made in these core classes in the trunk afterwards - all would be listed in CVS as modified by jglick with a clearly related message.
I am affraid this issue is not ready to be integrated into anything that will be released sooner than next version of NetBeans. There are still opened bugs (like issue 37005) that need to be solved before release. I do not suggest this to be backported. It might be simpler (because as far as I know you have your own launcher script) to lock the user directory there by creating some lock file. That might satisfy all architecture requirements. Ok?
Created attachment 12377 [details] Patch for release35R branch that does locking and only locking
The previous patch locks the user dir so another instance of ide can immediatelly exit or warn user that there is a lock left from the previous execution. It does not patch utilities/openfile and launchers, as that is too complex for backport. I'd like to repeat once again, that I do not consider this patch to be production ready. There will be new bugs related to this comming that is for sure.
Is there a release note here relevant for NB 3.6? "Only one IDE can use the same user directory at a time" seems like it would apply to quite a marginal audience.
You would think so wouldn't you? Yet perversely I have seen several people on the lists asking for help running multiple copies of the IDE with the same userdir in 3.6. I haven't really been able to figure out why they wanted to do this; usually I think they didn't realize you could e.g. have multiple debugging sessions running at once.
Patrick I guess you didn't see my last comment. I suggest RELNOTE be readded (no strong opinion).
re-added RELNOTE. BTW, I'm pretty sure I didn't get email notification of this and many other things I'm cc'd on. Have you noticed anything like this?