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 51482 - <javac> fails if ${user.dir} (e.g. NB install dir) not writable
Summary: <javac> fails if ${user.dir} (e.g. NB install dir) not writable
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: Tomas Zezula
Keywords: RELNOTE
Depends on:
Reported: 2004-11-13 04:24 UTC by athompson
Modified: 2012-07-30 20:40 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

ant debug output (47.74 KB, text/plain)
2004-11-13 04:25 UTC, athompson

Note You need to log in before you can comment on or make changes to this bug.
Description athompson 2004-11-13 04:24:11 UTC
windows 2000
4.0 daily 11/7/2004

1. log into windows 2000 as a user with admin
2. install netbeans to some directory
3. ensure install directory only has read
priveleges for all other users.
4. log out and log back in as a restricted user
5. start netbeans
6! try to compile a project. you get a build
error. see the attached debug ant output.

the problem is that netbeans tries to create a
temporary directory inside the working directory,
which is the install directory and not writeable
for the user.

another problem is that under normal ant output,
there is no clue given as to why the build failed.
it simply says, 'BUILD FAILED'. at least the
exception summary should be given.

a workaround  seems to be to modify the shortcut
for netbeans so that the working directory is some
directory where the user has write privileges. i
have no idea if that breaks something else. a
better solution would be to properly specify a
correct parent directory for the temporary
directory. i assume the proper location is the
netbeans default userdir.
Comment 1 athompson 2004-11-13 04:25:24 UTC
Created attachment 18878 [details]
ant debug output
Comment 2 athompson 2004-11-15 17:35:35 UTC
forgot to mention that i installed netbeans using the windows
installer. if the netbeans working directory is supposed to be
something other than the install directory, the problem lies with the

interesting, however, that netbeans works on the linux side without
being in a specific directory when starting. why is the code different?
Comment 3 Jan Chalupa 2004-11-16 08:24:42 UTC
Appears to be an Ant problem in the first place. Why should it create
a temporary file in a working dir instead of a temp dir?
Comment 4 Jesse Glick 2004-11-16 08:57:41 UTC
The version of in Ant 1.6.2 is

and has in executeExternalCompile

File userDir = getJavac().getTempdir();
if (userDir == null) {
    String userDirName = System.getProperty("user.dir");
    userDir = new File(userDirName);
tmpFile = fileUtils.createTempFile("files", "", userDir);

Why it uses this odd way of getting a temp dir, I have no idea. In
fact I had already independently patched this in my local copy of Ant
to read simply

tmpFile = File.createTempFile("files", null,

which would not pose a problem. I will try to commit that for future
Ant versions, but the problem with 1.6.2 remains.

Details: the <javac> task, if running in forked mode (e.g. you are
compiling against a non-default Java platform) *and* running with a
command length above 4096 characters, presumably meaning you have a
project with a lot of files in it or a large classpath, will try to
store arguments in some temporary file passed as e.g.

  javac @argsfile

This is fine, but 1.6.2's choice of temporary dir defaults to
${user.dir}, i.e. Ant's current working directory, which is arbitrary
when run from the IDE - currently may be the NB installation dir, but
that is probably platform-specific.

Possible workarounds:

1. Set the working directory of the IDE to be something writable, e.g.
the system's temp dir. Hard to enforce, though; depends on which
launcher is in use, etc. And I'm not positive what else this change
might affect.

2. Set


on all uses of <javac> in the project's build script. Should work,
though it is a little ugly, and will be obsolete (though harmless) as
soon as my patch is in an Ant release. Would need to be done in all
project types (so for D, j2seproject and web/project).

Candidate for a 4.0 HR fix, I suppose.

Re. message output in case of error - don't know much about it, would
have to see an output log, but normally Ant at regular verbosity just
prints an exception message or something, and prints a full stack
trace only with -verbose or -debug, under the assumption that these
are not *normally* user-level errors. I will also patch to
try to print a more helpful message such as

Error creating temporary file: C:\Program
Files\netbeans-4.0dev\files69258098 (Access is denied)
Comment 5 Jesse Glick 2004-11-16 08:58:15 UTC
Can certainly fix for 4.1, up to QA for 4.0.
Comment 6 Tomas Zezula 2004-11-16 10:08:04 UTC
Checking in build-impl.xsl;
 <--  build-impl.xsl
new revision: 1.46; previous revision: 1.45
Comment 8 David Konecny 2004-11-16 10:40:57 UTC
The same fix needs to be done for Web too. Also there might be other
tasks which behave similarly. <java>? Issue 51372 is about the same
problem for <javadoc> task, but it is planned for 4.1.
Comment 9 Tomas Zezula 2004-11-16 10:47:05 UTC
<java> has no support for reading opions from file. The <javadoc> can
be rewritten to use useexternalfile attribute.
Comment 10 Jan Chalupa 2004-11-16 13:00:15 UTC
Not a common scenario, workaround exists ->P2. Release note for 4.0.
Comment 11 Jesse Glick 2004-12-02 21:23:49 UTC
Note: <javac> bug fixed for 1.7 at least:
Comment 12 Jesse Glick 2004-12-02 21:28:59 UTC
A correction: issue #51372 does not appear to be the same issue. in ANT_162 has

  tmpList = fileUtils.createTempFile("javadoc", "", null);

which should be fine.
Comment 13 Jan Chalupa 2004-12-08 05:50:36 UTC
Waiver approved for 4.0.