Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 154904 - Unable to install NB 6.5 Patch1 as non-privileged user
Unable to install NB 6.5 Patch1 as non-privileged user
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Autoupdate
6.x
PC Windows XP
: P1 (vote)
: 6.x
Assigned To: dlipin
issues@platform
:
Depends on:
Blocks: 154537
  Show dependency treegraph
 
Reported: 2008-12-08 10:18 UTC by rbalada
Modified: 2009-08-21 11:51 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
patch which deletes problematic UT file prior to modifying it (1.84 KB, patch)
2008-12-09 17:04 UTC, dlipin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rbalada 2008-12-08 10:18:07 UTC
Hello,

as part of installation tests of NetBeans 6.5 Patch1 I was conducting following test.

Environment:
Windows XP Professional SP3
Java 6 Update 4 SDK
NetBeans 6.5 C/C++ installer
Install IDE as "Root", patch it as unprivileged user.

Steps to reproduce:
#1 Login as Administrator or similar privileged user in your Windows XP box
#2 Install NetBeans 6.5 C/C++ version, use Java 6 for NB runtime (Update 4 used in my case)
#3 Run NB 6.5
#4 In menu Tools->Plugins select tab "Settings"
#5 Disable Update Center called "NetBeans"
#6 Click Add button and enter new Update Center with URL
http://updates.netbeans.org/netbeans/updates/6.5/uc/final/stable/catalog_stage.xml.gz
#7 Select tab "Available plugins" and click "Reload catalog"
#8 Select tab "Updates"
#9 Install the only visible update for "Auto Update Services"
#10 here we can branch further steps in order to use or not use behavior described in issue 154026

Now let's *not* use behavior from issue 154026

#11 Choose "Restart IDE now"
#12 After IDE restart go to Tools->Plugins and check what's on "Updates" tab. You should be offered with an update for
"Auto Update Services" again

Now let's use behavior described in issue 154026

#11 Choose "Restart IDE later"
#12 Updates tab gets filled with the rest of available updates
#13 Install all updates
#14 When prompted for IDE restart, feel free to do it now or later. If you choose later, quit the IDE and start it again.
#15 After IDE (re)start go to Tools->Plugins and check what's on "Updates" tab. You should be offered with an update for
"Auto Update Services" again
Comment 1 rbalada 2008-12-08 10:20:10 UTC
Setting blocker relation to NB 6.5 Patch 1 staging request.
Comment 2 rbalada 2008-12-08 10:21:18 UTC
Updating with correct issue number.
Comment 3 dlipin 2008-12-08 11:45:24 UTC
Are there any exceptions in the messages.log?
Comment 4 pslechta 2008-12-08 11:53:45 UTC
java.io.FileNotFoundException: G:\download\nb\6.5fcs-ml\netbeans-6.5-20081110000
1-cpp\netbeans\platform9\config\Modules\org-netbeans-modules-autoupdate-services
.xml (Access is denied)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
        at org.netbeans.updater.ModuleUpdater.unpack(ModuleUpdater.java:385)
        at org.netbeans.updater.ModuleUpdater.run(ModuleUpdater.java:131)
java.io.FileNotFoundException: G:\download\nb\6.5fcs-ml\netbeans-6.5-20081110000
1-cpp\netbeans\platform9\update_tracking\org-netbeans-modules-autoupdate-service
s.xml (Access is denied)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
        at org.netbeans.updater.UpdateTracking$Module.write(UpdateTracking.java:
810)
        at org.netbeans.updater.ModuleUpdater.unpack(ModuleUpdater.java:433)
        at org.netbeans.updater.ModuleUpdater.run(ModuleUpdater.java:131)
Comment 5 pslechta 2008-12-08 11:55:20 UTC
It seems that the problem is with access rights again. The update file from the exception is in install dir and it seems
to me that updater is trying to overwrite file in the directory where it does not have modify/delete permissions...
Comment 6 pslechta 2008-12-08 11:56:12 UTC
The problem is reproducible with zip-based installation too.
Comment 7 dlipin 2008-12-08 11:57:13 UTC
Is "Force install into shared directory" checkbox enabled?
Comment 8 pgebauer 2008-12-08 12:20:17 UTC
The problems seems to be somehow connected to directory permission. Even though the properties in Windows explorer show the "Users" group is able to 
Read&Execute only, I'm able to create and change files under "Guest" account. Moreover IDE download the AU Service NBM into NetBeans install dir. It 
shouldn't. It should use user dir instead. If I remove permissions for "Users" group and set permissions "Read&Execute" for the "Guest" account only, I'm not 
able to create and change files anymore and the patch1 installations works well.

BTW If you try to check "Force install into shared directory" checkbox, you will get message "Shared directory <path to NB 6.5 install directory> is read-only. 
Cannot install into the directory"

Comment 9 pslechta 2008-12-08 12:25:40 UTC
The ckeckbox "Force install into shared directory" is not enabled. When I try to select it, it says that the directory
is read-only...
Comment 10 dlipin 2008-12-08 12:58:24 UTC
Looks like ui.Utilities and services.Utilities has different implementations of canWrite()/canWriteInCluster method.

ui.Utilities do the following:
1) gets update_tracking directory of the specific cluster
2) if it does not exist, then return cluster.canWrite()
3) if it exist, then it takes the first file in this directory and checks if it can write to this file.

services.Utilities do the following:
1) Takes "download", "update" or the cluster directory whichever exist
2) Checks if it can write into this directory by trying to create new dummy file and delete it afterwards.

Thus ui.Utilities checks if IDE can write (modify) existing file(s), and services.Utilites checks whether the IDE can 
write into existing directories (create/delete files).
Comment 11 dlipin 2008-12-08 13:08:57 UTC
Jirka,

I`m thinking of moving the check of tracking files modification (almost the overall ui.Utilities.canWriteInCluster() 
method) to services.Utilities.canWriteInCluster() and calling this global check method from 
SettingsTab.cbGlobalInstallActionPerformed method. Any objections or ideas why I shouldn`t do it?

Anyway I don`t see any fix that we can do now to fix this issue. Even though the fix goes into patch, user should 
install this patch as the privileged user. It can help only for the further patches.
Comment 12 Jaromir Uhrik 2008-12-08 13:53:53 UTC
Product Version: NetBeans IDE 6.5 (Build 200811100001)
Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)

I am not able to reproduce on my Win XP machine. The scenario is following:
-Install as administrator NB6.5 full distribution
-log in as a user with non admin permissions
-run NetBeans and add catalogs with latest patch
-install update (autopudate-services and updater are installed correctly to userdir)
-install all 17 updates 
Comment 13 dlipin 2008-12-08 14:03:32 UTC
I personally can reproduce it in the other minimalistic scenario
1) Extract any zip distribution
2) Make the whole (recursively) netbeans directory read-only by means of IE
3) Run IDE (I am the user with admin privileges) and try to update "Auto Update Services".

As the result I get the same FileNotFoundException exception (Access Denied) and update is not installed.
Comment 14 dlipin 2008-12-08 14:52:08 UTC
Rudolf,
Is "Auto Update Services" module updated if IDE is run under privileged user? 
If yes I propose to downgrade priority to P2.
Comment 15 rbalada 2008-12-08 15:04:05 UTC
Dima,

I've conducted a test with full distribution and JDK5 using "privileged" user and it worked fine, but I'm not certain
this can be used as a measure for priority downgrade. 
The worst part I experienced is that I was offered with an update and after "installation and restart" I was never
informed by updater about patch installation failure. This way a user can be prompted to install a patch every week, but
it never really installs and user does not notice it did not install. It could look like we release "weekly" updates.
Comment 16 pgebauer 2008-12-08 15:16:56 UTC
The issue is reproducible when a user is not Administrator and he has special permissions "Create Files / Write Data" and "Create Folders / Append Data" 
(please do not confuse mentioned permissions with "Write" permissions). Once these special permissions are removed, the update works. Also it works 
under the Administrator account.
Comment 17 rbalada 2008-12-08 15:26:06 UTC
Update: I was unable to reproduce on Linux with similar scenario.
Comment 18 dlipin 2008-12-09 11:20:12 UTC
I guess pretty much the same issue can happen on Linux/Unix if you set rwx permissions on directories but r-- 
permissions on update tracking files.
Comment 19 dlipin 2008-12-09 13:44:38 UTC
Just to note that my initial idea of using services.Utilities from ui.Utilities does not sound reasonable since 
services.Utilities is included in neither of the current public packages (org.netbeans.api/spi.autoupdate).
Comment 20 dlipin 2008-12-09 17:03:22 UTC
Rudolf, Jirka,

I propose the following patch to be applied UpdateTracking.java.
In two words, the purpose of the patch is to the following:
1) If updater (updater.jar) can`t modify the update tracking file (.xml) then it deletes it tries to delete it first.
2) If was is deleted, then create this file and write new update tracking information into it
3) If it was not deleted - than we back to this issue and can`t do anything about it. Such situation should be very 
rare since it would require that permissions are explicitely set on the update_tracking folder.

Should I push it to main/core-main first (before pushing to release65_fixes) or you can verify it without doing that?
It is really worth verifying that it cause no troubles in all possible cases of initial installation (root/non-root/
special privileges) and applying patches (root/non-root/special privileges).

In the long run (for 7.0) we should definitely add have reliable check for "write into cluster" functionality.
If it is worth I can certainly consider fixing it for 6.5 in the next patch (the risk of introducing troubles by that 
fix is rather high, unfortunately). 
Comment 21 dlipin 2008-12-09 17:04:53 UTC
Created attachment 74755 [details]
patch which deletes problematic UT file prior to modifying it
Comment 22 pgebauer 2008-12-09 17:37:52 UTC
All issues have to be fix and verified in the trunk before integration into any sustaining branch. The only exception is the situation when a source code isn't 
available in the trunk because of strong refactoring or function disappearing. Since you are the code owner, you can go ahead and integrate the change. QE 
should verified it and mark it as 65fixes2-candidate. 
Comment 23 Jiri Rechtacek 2008-12-09 17:52:00 UTC
The patch looks good, it can make AU robust a little bit, however AU will never guarantee that can work correctly in
such incorrectly setup of write/read permissions in NetBeans files, including userdir.
Anyway, it's not P1 that the sustaining cannot deliver NB6.5 patch, it should be decreased. In common cases (which were
tested many times) patch1 can be delivered, it means e.g. full NB6.5 IDE distribution has no problem with that. If there
is some bug in NB6.5/C++ installer, let's fix the problem there and don't fix its consequence in AU code IMHO.
Comment 24 dlipin 2008-12-09 20:55:07 UTC
Jirka,

There is no bug in installer, the issue is really in autoupdate. It does not depend on the installer distribution but 
depends on the privileges of the user that installs the patch.

The current logic that checks whether the update can be installed in the shared directory is not error-free.
In particual, in can be the case when the user can create/remove files in the shared directory but cannot modify 
existing ones (e.g. tracking update files). And it looks like users with such permissions is not the rare case.

In other words, AU (services.Utilities) makes the decision about shared installation based on the check whether the 
cluster directory is writable i.e. new files can be created there. Looks like it is not enough - we should also check 
whether we can modify existing files, in particual, update tracking (.xml).
Comment 25 dlipin 2008-12-09 21:24:33 UTC
pushed to core-main, #896c2cb94dff
Comment 26 Petr Suchomel 2008-12-10 10:52:17 UTC
Should this issue be closed? I see it was integrated but Target is still set up to TBD
Comment 27 dlipin 2008-12-10 10:56:36 UTC
right.
Comment 28 Quality Engineering 2008-12-10 16:52:46 UTC
Integrated into 'main-golden', will be available in build *200812101401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/896c2cb94dff
User: Dmitry Lipin <dlipin@netbeans.org>
Log: Issue #154904 Unable to install NB 6.5 Patch1 as non-privileged user
Comment 29 jarome 2008-12-16 16:21:40 UTC
I saw this too on OS X. But XP Pro updated just fine.
Comment 30 pgebauer 2008-12-16 16:33:56 UTC
I have tested the 65patch1 on Mac OS X Leopard as both privileged and non-privileged user without any problem. If you know the exact configuration (OS 
version a mainly user's permissions) when the issue appears on Mac OS X, please write them to this issue. It will be very helpful for testing.

Comment 31 jarome 2008-12-16 16:43:30 UTC
So, I am using an Intel 8-core MacPro with OS X 10.5.6.
I also have to apply the patch to get NetBeans to even launch by double-clicking the .app file, so they may be related.
http://www.netbeans.org/issues/show_bug.cgi?id=146119
Comment 32 pgebauer 2009-08-21 11:51:12 UTC
I was able to reproduce the issue on WinXP as Admin, Guest user with NetBeans IDE 6.7.1 and with
org-netbeans-modules-welcome.nbm and org-netbeans-modules-ide-branding-kit.nbm.


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