Bug 32054 - Lock user directory
Lock user directory
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
3.x
All All
: P2 (vote)
: 3.x
Assigned To: Jesse Glick
issues@platform
TCR
: API, ARCH, RELNOTE
: 32083 (view as bug list)
Depends on: 36047
Blocks: 31396 36472 36663
  Show dependency treegraph
 
Reported: 2003-03-17 16:04 UTC by Jesse Glick
Modified: 2008-12-22 20:12 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Patch for release35R branch that does locking and only locking (65.15 KB, patch)
2003-12-02 09:24 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-03-17 16:04:15 UTC
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".
Comment 1 Jesse Glick 2003-03-17 16:04:35 UTC
Probably requested by ARC.
Comment 2 Jesse Glick 2003-03-18 13:35:01 UTC
*** Issue 32083 has been marked as a duplicate of this issue. ***
Comment 3 Jaroslav Tulach 2003-03-18 15:55:27 UTC
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.


Comment 4 Jesse Glick 2003-03-18 16:40:31 UTC
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.
Comment 5 Jaroslav Tulach 2003-03-19 16:04:10 UTC
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.
Comment 6 Jesse Glick 2003-03-19 18:04:26 UTC
But Java provides no way to chmod go-r the lock file.
Comment 7 Jesse Glick 2003-03-19 18:09:50 UTC
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.
Comment 8 Jaroslav Tulach 2003-05-28 09:40:41 UTC
Some kind of proposal available at
http://openide.netbeans.org/proposals/arch/cli.html
Comment 9 Jaroslav Tulach 2003-06-03 07:58:36 UTC
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.
Comment 10 Jesse Glick 2003-09-10 00:08:12 UTC
Working on this, along with issue #31396. Marking FEATURE due to
presence of new API (CLIHandler) and associated capability.
Comment 11 Jesse Glick 2003-09-11 18:40:42 UTC
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
Comment 12 _ gordonp 2003-11-26 00:22:26 UTC
Sorry to reopen but we require this in the release35R branch (Rainier)
for our ARC case (we cannot release without this problem fixed).
Comment 13 Jesse Glick 2003-11-26 00:59:02 UTC
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.
Comment 14 Jaroslav Tulach 2003-11-26 14:21:53 UTC
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?
Comment 15 Jaroslav Tulach 2003-12-02 09:24:27 UTC
Created attachment 12377 [details]
Patch for release35R branch that does locking and only locking
Comment 16 Jaroslav Tulach 2003-12-02 09:28:48 UTC
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.
Comment 17 Patrick Keegan 2004-03-04 23:00:28 UTC
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.
Comment 18 Jesse Glick 2004-03-05 00:18:28 UTC
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.
Comment 19 Jesse Glick 2004-03-05 00:19:06 UTC
Patrick I guess you didn't see my last comment. I suggest RELNOTE be
readded (no strong opinion).
Comment 20 Patrick Keegan 2004-03-05 00:29:24 UTC
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?


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo