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.
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
Setting blocker relation to NB 6.5 Patch 1 staging request.
Updating with correct issue number.
Are there any exceptions in the messages.log?
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)
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...
The problem is reproducible with zip-based installation too.
Is "Force install into shared directory" checkbox enabled?
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"
The ckeckbox "Force install into shared directory" is not enabled. When I try to select it, it says that the directory is read-only...
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).
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.
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
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.
Rudolf, Is "Auto Update Services" module updated if IDE is run under privileged user? If yes I propose to downgrade priority to P2.
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.
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.
Update: I was unable to reproduce on Linux with similar scenario.
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.
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).
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).
Created attachment 74755 [details] patch which deletes problematic UT file prior to modifying it
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.
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.
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).
pushed to core-main, #896c2cb94dff
Should this issue be closed? I see it was integrated but Target is still set up to TBD
right.
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
I saw this too on OS X. But XP Pro updated just fine.
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.
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
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.