No more than one copy of NB should be permitted to
use the same userdir at once. Compare e.g. Mozilla's
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.
if [ \! -d "$lockdir" ]
chmod go-rwx "$lockdir"
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
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
Created branch lock_userdir_32054 rooted at BLD200306030100 for 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
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