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.
jdk-1_5_0_15-nb-6_0_1-windows-ml.exe (on Windows XP/Vista) 1. Start installer as the user(The UAC is switched off)/ There are no rights for installation JDK , but you can establish a NetBeans 2.Click Next Incorrect way for a NetBean on the panel of a choice of a directory of installation. (see att)
Created attachment 56458 [details] x
And what is the issue then? With the UAC turned off the installer is executed with no admin rights : such a user don`t have an ability to write to Program Files. Jan, what location should we use as the default, if the "C:\Program Files" is not writable (thus "C:\Program Files\NetBeans xxx" cannot be created)? I agree that leaving non-writable location and force user to pay attention to that and modify the installation path manually is not straightforward... On Unixes we install to user dir ($HOME) but as far as I understand user`s profile directory (%USERPROFILE%) is not used much on Windows (I can be wrong with that assumption). Certainly not P2.
actually the same applies to glassfish and tomcat - they both by default are installed to Program Files.
Should the installer ask for administrator privileges when installing NetBeans? That's what other installers do on Mac and I think that's the right solution. Another solution is to provide a reasonable default if the installer cannot write into Program Files. But, what is an expected default location in such case? On Win XP, I don't think there's a reasonable location we could offer. I tend to say it's maybe better to offer Program Files even if it cannot be used. It's sort of a warning the user is installing NetBeans as a non-admin user. I'm not sure about Vista. Any suggestions?
I tend to think that Windows (XP and Vista) differs from MacOS in terms of usage. In my understanding, Macs are usually used personally: there is usual only one user on the system. And he usually either has the admin rights or just knows the admin user/pass. Moreover, the password is always requested when installing on Mac independently on whether the user is in admins group or not. Windows users are different (speaking here about users with no admin rights). It is normal to have 2-3 users on the same systems and some of them have limited access. It is also a usual thing (in corporate environment) that the user don`t have admin rights : the administration can be done remotely and centralized. To summarize: Mac users usually have admin rights and asking them for a password is usual when installing any Mac software. Windows users often do not have admin rights and I don`t think that we should prevent them from installing NetBeans without admin rights. I personally don`t see any reasonable location alternative to Program Files as well as Jano. I guess, that windows users with such restrictions already know that they are not allowed to write to Program Files so they likely would not be much surprised to see that. The warning that we should is pretty much self-explanatory. So I tend to close the issue as INVALID. Jano, July, any objections? Just my $0.02 (and humble opinion).
Jano, I see the following options that we could follow: 1) Leave everything without a change. Warn user at the installation panel that C:\Program Files\NetBeans XXX (glassfish, tomcat) is not writable and force him change the directory. This option has one side and invisible (d)effect: if installer is run silently with default options and user don`t have admin rights, then the installation would fail. 2) Use %SYSTEMDIRVE% (C:\) as the default installation locations for such users i.e. install netbeans to C:\NetBeans 6.1, glassfish to C:\glassfish-v2ur, tomcat to C:\apache-tomcat-6.0.x. We don`t have a "silent" bug described at point 1 in such a case. 3) Use %USERPROFILE% (C:\Documents and Settings\<userid>) as the default installation location, i.e. install netbeans to C:\Documents and Settings\<userid>\NetBeans 6.1, glassfish to C:\Documents and Settings\<userid>\glassfish-v2ur1, tomcat to C:\Documents and Settings\<userid>\apache-tomcat-6.0.x. We don`t have a "silent" bug described at point 1 in such a case. What do you think?
I think the silent installation should permit the user to change the installation location. If it fails with the right warning, the user can specify a new install dir.
Jan, actually there is two kinds of silent installation simple and powerful. Simple installation is done via running netbeans-6.1-windows.exe --silent. User with unsifficient rights can`t install netbeans in such a way (the only option is to run under it Administrator). Powerful installation is done in two steps: 1) Create special file where all the properties (installation locations, ports for glassfish, java to be used by NB, etc) are set during installation on one system: netbeans-6.1-windows.exe --record state.xml 2) Using this file on other system to perform silent installation: netbeans-6.1-windows.exe --silent --state state.xml In such a case user can modify that xml file to modify netbeans installation location to the writable directory. Anyway the warning is not shown.. since it is *silent* installation. User can check either the exit code of the process and/or the logs for errors.
Using the silent installation which installs NB into an unknown location (e.g. "C:\" or any other location outside of Program Files on windows) doesn't seem to me like a real use case. I would say that also if it's a silent location we need to inform the user about errors, right? So I still think we should inform the user and explain how to go around the problem. Either using the xml file or some other way.
Well.. looking at other products installations I have an impression that they don`t inform about any problems (other than via exit code of the process) that occured in silent installation. The other critical thing that silent installation is not used much, I`d rather say it is used less than by 1% of users. And they know what they do and how to deal with silent installation. At the end, silent installation of one product is often used as the part of the installation of another big product. In such a situation the big product installer is capable of analyzing the exit code of the product that is installed silently and depending on the code, show its own error. We do provide instruction for silent installation and the way to change installation location. I don`t see any reason to keep this issue open now.