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.

Bug 126044 - installer does not honor tempdir
Summary: installer does not honor tempdir
Status: RESOLVED FIXED
Alias: None
Product: installer
Classification: Unclassified
Component: NBI (show other bugs)
Version: 6.x
Hardware: PC Solaris
: P2 blocker (vote)
Assignee: dlipin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-26 06:59 UTC by elkner
Modified: 2008-01-28 15:51 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description elkner 2008-01-26 06:59:58 UTC
Linux env: tmpfs                 256M  936K  256M   1% /tmp
           /dev/hda1             129M  119M   11M  92% /
           user 'root' has its home on /
           JDK 1.6_u4

neither netbeans-6.0-linux.sh --tempdir=/export/scratch/build/tmpb --javahome=/local/apps/jdk1.6
nor netbeans-6.0-linux.sh --tempdir /export/scratch/build/tmp --javahome=/local/apps/jdk1.6
as show in netbeans-6.0-linux.sh --help is honored, which leads to 
"Insufficient disk space for extracting the installation data. Additional 166,2 MB is required in /root/.nbi."

And pretty strange as well, during the install 'customize dialog':
tmpfs                 256M  170M   87M  67% /tmp

So even if instructed to use another temp dir, the stuff gets uncompressed to /tmp!
If one has a little bit more stuff in /tmp (e.g. on a sunray server), the installer 
doesn't even take the very first hurdle and stops with the "use --tempdir" error message ...

Furthermore, IMHO it's pretty brain damaged, to extract the stuff (2nd stage)? in the users home directory, 
especially if the installer has been instructed the installer to use another filesystem. Imagine, if the installing 
user/operator has its home on an NFS server [and possibly mounted its home read only for policy reasons] ...

The bug applies to Solaris (10u3, etc.) as well. 
env: /dev/dsk/c1t0d0s0      241M   159M        58M    74%    /
     swap                   256M     0K       256M     0%    /tmp
     JDK 1.6_u4

Last but not least, the installer should honor the TMPDIR env variable ...

(BTW: Dear windows developers, please let your UNIX collegues have a look at the installer before releasing an
uninstallable package ...)
Comment 1 dlipin 2008-01-26 21:12:47 UTC
Dear elkner,

> neither netbeans-6.0-linux.sh --tempdir=/export/scratch/build/tmpb --javahome=/local/apps/jdk1.6
> nor netbeans-6.0-linux.sh --tempdir /export/scratch/build/tmp --javahome=/local/apps/jdk1.6
> as show in netbeans-6.0-linux.sh --help is honored, which leads to 
> "Insufficient disk space for extracting the installation data. Additional 166,2 MB is required in /root/.nbi."

Actually "--tempdir" installer switch is used for the initial data extraction before the GUI appears (one big 
bundle.jar with all the data) and it is also used as the java.io.tmpdir system property.
Additionally during the installation some data is extracted to the ".nbi" subdirectory in user home directory (taken 
from user.home java system property) so that it is used for installation and further unstallation. We can`t put all the 
data in the tmp directory since it can be deleted on regular cleanup so that the futher uninstallation would not be 
possible.

> And pretty strange as well, during the install 'customize dialog':
> tmpfs                 256M  170M   87M  67% /tmp

> So even if instructed to use another temp dir, the stuff gets uncompressed to /tmp!
> If one has a little bit more stuff in /tmp (e.g. on a sunray server), the installer 
> doesn't even take the very first hurdle and stops with the "use --tempdir" error message ...

> Furthermore, IMHO it's pretty brain damaged, to extract the stuff (2nd stage)? in the users home directory, 
> especially if the installer has been instructed the installer to use another filesystem. Imagine, if the installing 
> user/operator has its home on an NFS server [and possibly mounted its home read only for policy reasons] ...
The only place where the installer can store its installation data with guaranty of no deletion and write access is the 
user home directory. If the user has no write access to its home directory then he can do nothing. He is not able to 
use the installer. He is not able to run NetBeans with default settings.
If you want to override the directry where the installer would store its installation data run the installer with --
userdir <any-dir-with-write-access-and-enough-space> option.
If you run it with "--userdir ~/.nbi" you`ll get the things go like in default behaviour.
You can run it with --userdir /tmp/.nbi" if you have enough free space in /tmp (and additonally, with --tempdir /tmp to 
extract initial data at /tmp as well).

> The bug applies to Solaris (10u3, etc.) as well. 
It is not the bug but the feature.

> env: /dev/dsk/c1t0d0s0      241M   159M        58M    74%    /
>      swap                   256M     0K       256M     0%    /tmp
>     JDK 1.6_u4

> Last but not least, the installer should honor the TMPDIR env variable ...
Why? 
It should not, really. But it respects TMP and TEMP env vars.

> (BTW: Dear windows developers, please let your UNIX collegues have a look at the installer before releasing an
uninstallable package ...)
dear elkner,
I can`t but grieve you.
From the early beginning of NetBeans installer development we were respectful for users of all oses and flavours that 
are proclaimed to be supported and tested : all modern windows (2k/xp/vista), all recent macosx (tiger & leopard), all 
latest stable and development solarises (9,10,11 within various distributions, both sparc and x86) with special 
attention to a great variety of linux systems (a big number of Ubuntu`s, RedHat, OpenSuse, Fedora, Gentoo, etc, x86 and 
x86_64).
Not only the development but a big number of internal quality engineers as well as external users gave us the feedback 
on the installer under different unixes (and we know what is NFS since we use it almost everyday).
During the last year of development we collected the great number of issues (hundreds) and problems that could occur 
under certain circumstances, all critical and important were fixed, almost all the rest that are known and not yet 
fixed are minor and does not affect functionality.

With a great respect to your opinion about our work and brains I have the only option to close the issue as invalid.

Thanks,
Dmitry
Comment 2 dlipin 2008-01-28 14:41:13 UTC
Reopening...

I`ve just checked and neither TEMP nor TMP nor TEMPDIR is never used to get the tempdir.
Comment 3 dlipin 2008-01-28 15:51:03 UTC
Fixed for 6.1:
http://hg.netbeans.org/main/rev/df0cbbb2955f