Created attachment 142851 [details]
stacktrace

>java.io.IOException: There is not enough space on the disk
The /tmp volume is full.

lucene/maven indexer is using java.io.tmpdir to unzip the downloaded index and to create the lucene index (which is later moved/copied to netbeans cache dir. We don't have a direct way of influencing this AFAIK.

the workaround is to set -J-Djava.io.tmp=<path where is enough space> in <nb install directory>/etc/netbeans.conf

Maybe it would make sense to tell the user in the gui about this functionality, eg in Options->Java->Maven->Index.

There we could have some sort of 'Warning' or other Info if the space in the lucene folder is getting low. Sth like:

'Current Lucene Temp Folder: C:\temp, 1 GB available'
'Warning: There is not enough space for the lucene index to be created'
'Info: You can change the lucene temp directory via the option -J-Djava.io.tmp=<path where is enough space> in <nb install directory>/etc/netbeans.conf

Shall I create a new Enhancement Request for this?

(In reply to tomzi from comment #5)
> Maybe it would make sense to tell the user in the gui about this
> functionality, eg in Options->Java->Maven->Index.
> 
> There we could have some sort of 'Warning' or other Info if the space in the
> lucene folder is getting low. Sth like:
> 
> 'Current Lucene Temp Folder: C:\temp, 1 GB available'
> 'Warning: There is not enough space for the lucene index to be created'
> 'Info: You can change the lucene temp directory via the option
> -J-Djava.io.tmp=<path where is enough space> in <nb install
> directory>/etc/netbeans.conf
> 
> Shall I create a new Enhancement Request for this?

And how does one figure that out from java code? I mean how many GB are free on a given volume on all supported OS platforms?

doesn't this work reliably? 
from: http://examples.javacodegeeks.com/core-java/io/file/get-free-disk-space-in-java-example/

package com.javacodegeeks.java.core;

import java.io.File;

public class DiskSpaceDetail {

	public static void main(String[] args) {

		File diskPartition = new File("C:");

		long totalCapacity = diskPartition.getTotalSpace(); 

		long freePartitionSpace = diskPartition.getFreeSpace(); 
		long usablePatitionSpace = diskPartition.getUsableSpace(); 

		System.out.println("**** Sizes in Mega Bytes ****\n");

		System.out.println("Total C partition size : " + totalCapacity / (1024*1024) + " MB");
		System.out.println("Usable Space : " + usablePatitionSpace / (1024 *1024) + " MB");
		System.out.println("Free Space : " + freePartitionSpace / (1024 *1024) + " MB");

		System.out.println("\n**** Sizes in Giga Bytes ****\n");

		System.out.println("Total C partition size : " + totalCapacity / (1024*1024*1024) + " GB");
		System.out.println("Usable Space : " + usablePatitionSpace / (1024 *1024*1024) + " GB");
		System.out.println("Free Space : " + freePartitionSpace / (1024 *1024*1024) + " GB");
	}
}

Nice, I wasn't aware of this addition to File. However the javadoc is not so encouraging: 
"The number of unallocated bytes on the partition or 0L if the abstract pathname does not name a partition". 

It's likely fairly easy to know what a partition is on windows, however on linux it's not that easy to figure, or am I missing something?

let's make it an enhancement request and examine possibilities here for the next release

Yeah, I also get surprised by helpful new JDK addtions here and then :)

I mean - I'd guess these methods are just wrappers for actual system calls - so they should work in any circumstance - at least getFreeSpace()...

(In reply to tomzi from comment #10)
> Yeah, I also get surprised by helpful new JDK addtions here and then :)
> 
> I mean - I'd guess these methods are just wrappers for actual system calls -
> so they should work in any circumstance - at least getFreeSpace()...

indeed, at least on mac for any existing file/folder it shows the size, on non existing ones 0

I've resolved with a workaround in windows 7.
java.io.tmpdir uses %userprofile%TEMP (or %userprofile%TMP) for java.io.tmpdir.
Disconnect your %userprofile%. As administrator access controlPanel > UserAccounts. 
Select the %userprofile% and "Modify Enviroment Variables". 
Change the path for TMP and TEMP variable to a disk with enough space.
Reconnect your %userprofile%.

I've also been hit by this regularly.

I'm on linux, so the stuff goes into "/tmp", which is configured for 8 GiB, so plenty of space for indexing - at least I thought so.

The failing index (at least right now) is:
https://oss.sonatype.org/content/repositories/releases/.index/nexus-maven-repository-index.gz

...which is ~257 MiB in size and contains ~2.3 GiB of uncompressed data:

$ gzip -l nexus-maven-repository-index.gz
         compressed        uncompressed  ratio uncompressed_name
          269238983          2479070257  89.1% nexus-maven-repository-index

...nevertheless, the "unpacking" fails with a behavior similar to the good old zip-bomb:

...
[2015-01-21T09:42:05] total=8.0G, used=5.5G, free=2.6G
[2015-01-21T09:42:06] total=8.0G, used=5.6G, free=2.5G
[2015-01-21T09:42:07] total=8.0G, used=5.6G, free=2.5G
[2015-01-21T09:42:08] total=8.0G, used=5.7G, free=2.4G
[2015-01-21T09:42:09] total=8.0G, used=5.7G, free=2.4G
[2015-01-21T09:42:10] total=8.0G, used=6.7G, free=1.4G
[2015-01-21T09:42:11] total=8.0G, used=7.9G, free=154M
[2015-01-21T09:42:12] total=8.0G, used=8.0G, free=96M
[2015-01-21T09:42:13] total=8.0G, used=8.0G, free=47M
[2015-01-21T09:42:14] total=8.0G, used=7.9G, free=190M
[2015-01-21T09:42:15] total=8.0G, used=6.1M, free=8.0G
...

This bug already has 50 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=203801

I have tmp mounted as tmpfs, size=2G. Can you provide an appropriate value for such a setup?

*** This bug has been marked as a duplicate of bug 250365 ***