The only way to find free disk space appears to be by a 'guess'
algorithm that attempts to create different file sizes...not 
acceptable.

======================================================================




Please add someting like statfs() or GetFreeSpace(), that 
allows to determine number of total, used and free blocks 
on a filesystem to java.io.File.
My program could be 100% Java, is this is solved.
======================================================================




Please fix bug ID 4071324 in time for the 1.3 fcs release.
I know its in the database but some bugs just seem to slip by each release.

Thanks,
James

8/26/99   xxxxx@xxxxx   -- (dupe of 4057701)
(Review ID: 94446)
======================================================================




 DESCRIPTION OF THE PROBLEM :
There is no way to determine free disk space in a platform-independant way.

For each platform there exist a simple way to determine free disk space (or user-dependant quota) - but there is no api function in java available to
use this required and often requested feature.

(Review ID: 163627)
======================================================================1
  xxxxx@xxxxx   2004- customer -04
  xxxxx@xxxxx   10/15/04 20:41 GMT

======================================================================

A simple method or two for determining free disk space will be added to the java.io.File class in Mustang, which is scheduled to ship in
mid-2006.

  xxxxx@xxxxx   2005-1-28 21:40:10 GMT

Resolution of this request is considered a high priority for Mustang.
Active development on this feature has been in progress for the past
several months.  I expect that we will complete this work within the
next couple of months.  These methods will be in Mustang-beta.

  xxxxx@xxxxx   2005-03-01 21:30:38 GMT

It would be really nice to provide a function that returns the amount of free
space on some device / directory / disk drive. One way of overcoming the
problem is to exec a OS-depended program/script that returns the number of
bytes available on some drive. This way when the OS-independent <grin>
application is moved to another platform, one just has to rewrite the
program/script that will work for that OS. Another way of course would be to
resort to native calls, but that's even more work in my opinion.

Yes practically anything could be done using non-Java programs, scripts or JNI.
However for something so basic as determining the space available for files in
a file system I feel this should be put into pure Java. 

Hey guys I really need a call to find the free disk space.
I am pretty desperate for this. Please do something as
soon as possible.
Kaushal Cavale
kaushalc@hotmail.com

Too late for Kestrel!
When do you have to submit RFEs for them not to be too late.
I thought 2+ years would be more than adequate!

IWBNI we also got an indication whether the file system could accept another
file entry. (Some environments limit the number of files that can exist, as
well as the space available to store the data the file contains.)

You can find the the workaround under: 

http://www.jsiinc.com/tip1000/rh1071.htm

You can catch the output of this batch file and do with it 
what ever you want :o) (for now)

how to get the free disk space of the system.

There's no nice way to get the amount of free space
remaining in an arbitrary directory (there's loads of
variation between different UNIX variants in this area,
alas) and it isn't necessarily a useful figure either (e.g.
in the presence of disk quotas.)  Yuck.

It's true that there is "no nice way" to get this information.  That's
exactly why Java should give a simple way to access it-- so all the
"not nice" stuff happens behind the scenes, and I don't have to write
it into every Java app I create.

In order to take system differences into account, I think I'd need
two methods, to tell me what I could write to a given directory.
One, getLargestPossibleFile() would return the size of the largest
single file I could write in a dir.  The second, getPossibleFileCount(),
would take a filesize as an argument, and tell me how many files
of that size I could create there.

As a Java programmer, I shouldn't have to care how un-nice the 
implementation of those methods is. If my app needs to generate a huge
file (or a multitude of tiny files) over the course of four hours' processing,
I really don't want find out at 99% completion that my disk is too small.

If I wanted to muck around writing system-dependent code to check
something this basic, I'd still be using C++.

We have many file systems where the total size of files 
exceeds the raw capacity of the storage device. So even 
today the free space on a device is just a vague indication 
of the size of files that could be added. I think this 
situation is likely to get worse in future --- there may be 
no fixed association between a file and any specific 
physical device, the OS will just attempt to store the data 
somewhere.

how about an abstract class java.io.Volume extends File ? (for disks, network file stores, etc).
Sub-classes provide info eg number of blocks, whether it's a removable media, file system used.

new methods:

public long Volume.getFileCount() // current number of files on this volume

public long Voume.getMaxFileCount() // max number of files currently possible

public boolean Volume.canAdd(String bytes, String filename) 
// returns true iff "new File(filename)" would succeed and "bytes"  could then be successfully written to
the new File.  Perhaps it should also consider security policies?

public void Volume.add(String bytes, String filename) throws IOException, SecurityException
//tries to add a new File on the Volume, consisting of the bytes contained in "bytes", and with a filename 
given by "filename".

public long Volume.getMinAvailableFreeSpace() // minimum guaranteed available free space

public JTree File.getTree() // returns JTree of the file's/volume's file-system hierarchy, from the 
File's/Volume's level and deeper.

Try JConfig:

  http://www.tolstoy.com/samizdat/jconfig.html

For a comparison of JConfig with the core Java API, see:

  http://www.tolstoy.com/corejava.html

We're working on a full scale document management system 
which needs to handle very large amounts of data spread 
over lots of disks. It stinks having to write native code 
just to get the free space of a path. It's not feasible 
to "just" keep trying paths till it fits or worse yet, 
trying to copy it to 20 different disks only to find out 
you never could have fit it anywhere to begin with.

I have made a java program that does file management,
Copying files to and from different drives. The program 
test if there is enough space to copy a file correctly 
before it copies. At the momement I am using a wrapper to 
a  C class that has the needed method. I would like to have 
a pure java program. I can not believe that Java will not 
do this.

"SAT JAN 17 02:04 A.M. 1998" was the first request...
now we have August 2001. It's time to implement...
it's not a rfe... it's a bug!

This little bug can be easily fixed! There are functions in 
Win32 and Unix that are simple to use and there is a 
nice "Volume extends File" proposal here in the list. Don't 
wait another two years.

This 'bug' was reported over four years ago and it seems a 
fairly fundimental feature to have. Come on, Sun, you've 
been so good to us - don't let us down now! It can't be 
that hard to include it in the JVMs?!

This needs to be fixed. This is my last Java project until 
this bug is fixed, this bug negates the positive of java 
being platform independent because the fix is platform 
dependent.

I just really need a call like this, i donīt want to use 
JNI or exec method.

Hi,
I need to know what space is free on a remote drive.
The only way seems to call a rmote program to have the 
information.
Moreover this program must be platform dependent by calling 
a sysem procedure.
This is not acceptable.
Please implement.
best regards.

I've written a native method to do this --- works under 
Windows 2000 SP2.  If anyone needs it, just email me.

The lack of a pure Java solution to disk space query
is painful. Even more important now given the 
appearance of a decent JDK implementation on the 
Mac OS X platform. 

This bug was filed on Jun 09, 1997, and today is March 20,2002.
Almost 5 Year, How much time it will take to fix ?

I think sun forgot about this one!

Jun 09, 1997 Bug submitted,
July 16, 2001 "considered" in a future release".
It's 9 months later.  Sun, get your act together and get 
this written.  Just a single method getBytesAvailable() on 
a file.  What the heck is your problem people?

Having this broken on file systems where getting this 
information easily is not a problem sucks.  It's like 
peanilizing the users of OS's that can get this information 
easily.  MAC and PC's don't have this problem.  Just 
implement something, and "let there be" bug reports based 
on implementations that don't properly implement the 
feature.

And in which future release will it be considered?!?

Would that be my future, or a future in some paralell 
universe?

er... parallel

June 9, 1997 to July 9th, 2002 will mark the five year 
anniversary of this bug/rfe.  Happy 5th! 

1.1.3, 1.2.1, kestrel-beta, 1.1.1, 1.3.1, what are we at, 
1.4.1?

This is NOT a bug.  If the method were implemented and
didn't work correctly, then it would be a bug.  This is a
missing API (As the suggestion for a Volume class
demonstrates.)  Adding a method to File would be awkward -
there needs to be a way to detect physical Disks and
partitions/volumes.  Part of the problem is given
multi-processing machines - is it really useful to conclude
that when I started my process there was enough disk free
space and when I concluded the space was used by some other
process?  I use JConfig - Simple/Clean/Portable.

It would be a useful feature when attempting to write files. 

pls put it in

Yeah this is a big problem, I worked around it using exec and 
scripts. To call things like dir on windows and du/df on Mac 
and unix variants. it is not the greatest way, but it works.

it'was a great idea to hide the rfc list from website... but this 
fixes not the open bug (or so called rfe)...
there is no platform-independant way to determine free disk-
space (since 1997!!!) - an .NET grows up!

I would love to see this as well -seems like a common need 
with an annoying work around.

If you are interested in this issue, you may also be interested 
in 4285834.  Please vote for that RFE if you can!

This would definitely be a nice feature.

Inclusion of this functionality should have been a no-brainer. 
How this has been left out of Java for so long, I'll never 
know, but I hope the guys at Sun wake up.

would be _really_ nice to have

from 1997 to 2002 : 5 years, this is long to decide for this...

still waiting...

I think it is not acceptable to begin to write something like a 
c-programm with JNI to get this information. Should be part of 
the API to ensure that it works on Win, Unix, Mac,...

This is certainly a needed feature.  I won't pretend to 
understand how is could be implemented on a platform-
independant way but if we could at least get it started by 
implementing on platforms (Win32, Mac, Linux/UNIX) that 
have a known way of returning this information. 

Another programming language, PHP supports this feature and 
it runs on all of the above platforms (as well as others).

Come on Sun don't betray the faith with have put in you and 
Java.

Who is working on this?  No eval since 2001/7/16???

5 years 4 months and counting.  SUN!

So, how does PHP get the available disk space?  Does it take 
into account quotas?  Does it work with NFS?  Does it work 
with AFS?

i just can't believe that the best advice on how to find 
disk/volume/drive info is "use native code"!! if i want to use 
other languages why do i need java?? i think it's about time 
this is somehow added to the API

File.list() also needs to be fixed to deal effectively with 
100,000 files in a directory.  There needs to be an Iterator 
interface that goes down to readdir() or something so that 
we can get the file names one at a time, and not 100,000 in 
a String[] to loop through.

This will be considered in a future release.
-- xxxxx@xxxxx 2001/7/16
WHAT FUTURE RELEASE?   There have been a dozen releases 
since 7/16/01.

In this case it means in the new filesystem API being worked 
on for Tiger (1.5).
The RFE number is 4313887 and it is in JSR 203:
http://jcp.org/en/jsr/detail?id=203
Mike McCloskey

Ok, so we know this is a PITA. If my vote counts here, 
please, please provide API that allows better I/O access for 
anything from monitoring applications to ad-hoc querying. 

For example, it would really help if the application would know 
when free disk-space is approaching critical levels, etc. 

My vote is +1.

See
http://forum.java.sun.com/thread.jsp?forum=54&thread=332370&start=0&range=15#1717923
for a possible "sollution"...

This is really needed! Creating temp files up until the drive is 
full is not a "recommended" way of working, especially on 
sensitive systems where there must never be an outage on 
disk space!

This is a much awaited feature,we need some methods where 
we need to get all available statistics of a any disk drive,in 
pure java.Creating a native program defeats the whole 
purpose of using Java.
 - Oliver

Well, 1.5 scheduled for beta release at the end of the year.  
Still looks as though this fundamental feature is not getting 
implemented.

How does Sun expect Java to really get a foothold on the 
desktop and/or server market if we cannot even check if 
there is enough disk space to perform a request.

For each platform there exist a simple way to determine free 
disk space but there is no api function in java available to
use this required and often requested feature.
I am pity for it, and I hope we will get the pure java method 
in futrue!!!

OK, I'm sorry. Of course it is in the Top 25 RFE's.

This bug has 417 votes at this moment, but it does not 
appear in the top 25 bugs list allthough no. 2 in the list has 
currently just 324 votes !???

Uh guys, Jun 09, 1997, um could we pretty please have some 
half-baked thing that sort of works?  Uh, it's Septemer 2003 
now, 6 years.  Wow.

There are several other methods that should be implemented
imn the core since they are vailable on _all_ OSs:
getDateCreated(); getDateAccessed() - these sound esoteric
but can be must-haves for things like virus detection,
versioning, auditing, and library management software.

I think that if time will be spent building the native call
to the various OSs to get free space, that they should close
the circle by adding these fundamental Filesystem (hint)
methods as well. getMaxFileSize() is another.

This feature is a must.

This should be part of the java api.  

Don't read before 2020!

Ok, so it's year 2020. Two questions for you:
1. Is method getAvailableSpace implemented in some 
standard Java API?
2. Have they found Hussein Saddam?

Ok, this is ludicrous. It has been years since this was 
introduced, and still no progress. This is so basic, it's absurd 
to not be included in the base Java API. I need to write a 
monitor for disk space such that an administrator can be 
notified when the free disk space is reaching a critical point. 
And now you're telling me I need to write native code to 
determine something as basic as free disk space?

Instead of referring to it as "disk" space, how about referring 
to it as "physical storage" or even "permanent storage" 
space? I don't care what you call it, but the ability to 
determine the amount of free physical storage space is so 
fundamental, it's preposterous that it isn't already included in 
the base API.

the trick posted by HRogge above (which uses 
RandomAccessFile by probing which calls fail) doesn't 
work on Mac OS X - it actually creates the file and uses 
the space, causing the system to become very 
unhappy.

please add this api... has anyone found a decent 
workaround?

what did I have to read? again shifted...
JavaOne 2003 Notes
"JSR 203 (son of NIO) eg asynch I/O not in 1.5, have to 
wait for 1.6"
http://www.unidata.ucar.edu/staff/caron/java/JavaOne20
03.html
the people at sun have humor...any schedule for 
release 1.6? 2006... 2007... 2008? 10th anniversary of 
this rfe? nice try sun! :-(

1.5 & still no sign of this feature.

I appreciate Sun's efforts to make everything 100% 
Java but is Java itself 100% Java.  I cannot believe that 
the same code is used on both Linux, Solaris & 
Windows.

As long as the feature is added to all versions of the 
JRE/JDK I cannot see a problem.

>2. Have they found Hussein Saddam?

Hussein Saddam: found, shaved and enjoying the 
company of the CIA

java's fundamental file API: N/A

they're now after Osama again - which will happen 
first?

On Jun 09, 2004 is the 7th anniversary of this (again 
shifted) rfe - thank you sun.

when is 1.6 scheduled? 10th anniversary?!

what is taking this so long?

"This RFE is part of JSR-203 (see 
http://www.jcp.org/en/home/index), which is
targeted for J2SE 1.6.
xxxxx@xxxxx 2004-02-04"

Hmm?! JSR-203 is saying something different:

"2.2 What is the target Java platform? (i.e., desktop, 
server, personal, embedded, card, etc.)
This specification is intended to become part of the 
Java 2 Platform, Standard Edition, version 1.5 ("Tiger") 
as specified by JSR 176."

Next try...

I wrote a small JNI library called mogio to rid these
shortcomings, it's very simple and works by extending
java.io.File and adding the long missing methods, homepage
is available at http://mog.se/mogio.html

It's only distributed as a part of DrFTPD but if there's
interest i can make it a separate package.

It's been tested and works well under Linux and Windows 2000/XP.

eh?

Runtime.exec( "mkfifo out" );
Runtime.exec( "mkfifo in" );
Runtime.exec( "read cmd | out < in" );

Yes, this would be a very nice feature indeed!

Hmm... Think about this: if you get the amount of free
space, what guarantees you the space will still be available
if you create a file? Getting free diskspace is not an
atomic operation.

I think it's best to just create the file with the size you
need. If there's not enough free disk then catch the
exception. If it works, then you are guaranteed that space.

That's not the point.  Consider creating log files.  I want 
to know when the file system is getting full so I can 
take an action.  It's not just for creating files.  Also, for 
things like CD ROM's, or removable media it is often 
necessary to know how much space is left for things 
like backups.

This issue is a perfect example of why .NET is 
spreading. This RFE was submitted 7 f---ing years ago!
Every platform has this functionality

ridiculous, good example of extreme ignorance ...

Although this can be solved using JNI why not solve
it properly once and for all? OS issues won't go away
just because we don't like it...

HOORAY!!!!

Happy Birthday To You!
Happy Birthday To You!
Happy Birthday Dear 4057701!
Happy Birthday To You!

4057701 is 7 YEARS OLD today!

Those responsible should get a spanking, one for each year.  And one to grow on.

I'm going to have cake for lunch to celebrate.

Please provide at least a temporary fix in 1.5. To wait for 1.6 means another 2 years until it MIGHT be in.

wow this is ridiculous, shame on sun!

I love Java with all my heart, but this is simply irresponsible and stupid!

7 YEARS???!!!!

2000: 1. Anniversary

2001: This will be considered in a future release.

2003: This RFE is part of JSR-203 (see http://www.jcp.org/en/home/index), which is targeted for J2SE 1.5 (aka Tiger) - or new - J2SE 5.0 

2004: This RFE is part of JSR-203 (see http://www.jcp.org/en/home/index), which is targeted for J2SE 1.6 (J2SE 6.0 or J2SE 60.0 ?!)

2005: ?! J2SE 1.7 / 7.0 /70 ?! First men on the mars?!

Welcome in the world of Sun... and it's new partner Microsoft.

Open the source of your f---ing virtual machine. So we can correct it ourself.
Money talks again.

"Open the source of your f---ing virtual machine. So we can correct it ourself.
Money talks again."

And that's exactly why Sun should not listen to any of the crap people like you spout.
Close this thing and let it rot. There's no need for files anyway, just use a database for storage instead...

Rippuru had asked  On 19-APR-2004 why not just write out the file.

Well the best reason is to find out how close on disk space you are.  For example on linux if you fill up a partition and have other threads that are writing to the same partition you have the possiblitity of writing out 0 byte files because the space was taken up.  Trust me this is easy to have happen.

Another reason is that it looks like if you try the raf work around on Mac OS it is broken.

Right now I will be using the suggestion of allocating a random access file, but not writing it out to check the potential available disk space.  

Hopefully, this api request will happen before we all more onto another programming language.

While I am aware of the fact that Sun has many intentions for Java and that these sorts of tasks should be prioritized, the amount of effort involved in providing this kind of functionality is ridiculously minimal.  I have a great deal of respect for Java, but using RandomAccessFile to allocate disk space until you hit the limit to determine file size is like using a busy wait loop to determine how fast your CPU is: irresponsible programming and lacking the consideration that your software has to operate alongside other software.

This is a very serious failing in the Java API.  -Please- provide some form of fix soon.

Please add this feature.  It's important for java to be able to perform simple tasks like this.

Simple JNI (maybe not save or nice, but it works):

JNIEXPORT jlong JNICALL Java_NativeUtils_getFreeDiskSpace 
(JNIEnv *a_Env, jobject a_Obj, jstring a_File)
{
    const char *str = a_Env->GetStringUTFChars( a_File, 0);
	
	PULARGE_INTEGER freebytes = new ULARGE_INTEGER;
	PULARGE_INTEGER totalbytes = new ULARGE_INTEGER;
	PULARGE_INTEGER totalfreebytes = new ULARGE_INTEGER;
	
    GetDiskFreeSpaceEx
    ( 
    	str,
    	freebytes,
    	totalbytes,
    	totalfreebytes
    );

    a_Env->ReleaseStringUTFChars(a_File, str);
    return (jlong)(*freebytes).QuadPart;
}

The comments on this RFE are hilarious. I don't know if I agree that this is a *must* have for Java, since I don't think a lot of people are going to use it, but geez, this is sure taking a long time ...

Somebody should contact "koltsal", the original poster, one wonders if he/she already implemented this in JNI or just gave up on Java in that project.

sellhorn: "since I don't think a lot of people are going to use it"

imagine you are writin' an application that need q huge amount of space on harddisk (i. e. the Java Media Framework or a web application that stores a huge amount of large upload files). isn't it better to know the free disk space before you start long taking actions?!

and... it's a simple standard feature and easy to implement. the advice to use jni means to use c/c++. 

why i should use a platform independant programming language like java if basics are missing?

Well, looks like mvanveen fixed this bug.  Howzabout rolling it in Sun?

(Seven years, sheesh, that's pathetic lol)

Having left a facility for this out for 7 years since the initial request cannot possibly be an issue of 'not soon enough for the next release'.  This is just a case of the development team putting it in the too-hard basket instead of solving the problem. It's insulting to have the state listed as 'in progress'...

Surely a simple initial solution can be added to cover the simple cases and return -1 (unknown) if it cannot ascertain the available space - this allows for systems where a storage medium may not be able to deliver a reasonable estimate of available space.

Of course on the majority of systems it must be an estimate of actual space for file-content (exactly as most native commandline facilities provide), and even then, having available space does not mean you can create new files/folders as other conditions may apply.

Come on Sun implement a solution - get it sorted.

At least they put a landmark to it: J2SE1.6

JSR-203

This atitude is an insult to entire community. Obviously enough, Sun doesn't give a s*** about anything but themselves . They might just as well reveal their true intentions so we can abandon the sinking ship before it's too late. But they won't do that either, and I'm afraid it's already too late.

What's so difficult about extending the API? 

I currently use JNI calls for OS X and Windows XP, but this is then another component to distribute and seriously compromises the 'run anywhere' ethos. 

All we need is an API call like 'bool isSpaceAvailable(long numBytes) throws IOException' in the java.io.File class...

It definately should be in, 
Solves lot n lots of troubles

I read through all the docments about java classes and find no function to obtain the total disk space,used space and free space,it is really a defect of java. this demand is basic!

Please fix this.  It shouldn't be that hard.

Still Waiting......

Still Waiting......

What should we get 4057701 for Christmas?  How
about a Shiny New Bike.  If 4057701 was a kid it would
definately be old enough to ride a bike by now.

This is not a simple problem to fix in the general case.  In Windows with everything installed on C: running as administrator it

This is not a simple problem to fix in the general case.  In Windows with everything installed on C running as administrator it's easy. (Unless you have compressed folders!)

Consider the case where I'm running on a unix box as a none priviledge user with a quota set.  There are 20 volumes mounted, 10 of which are virtual volumes from my SAN and 5 are network volumes.
Now, how much disk space is free?  Well plenty, let's say 20TB.  What's the biggest file that can be created.  Maybe only 16GB.  What's the biggest file that I can create?  Well that depends in which folder I want to create it in and which filesystem that  folder is mounted on.

On solaris the /tmp folder is mounted in virtual memory.  So the free disk space depends on system load.

On my mobile phone there is no disk.

So while it may seem bizarre to have such an old defect,  any one way of implementing it would not please all in a cross platform manner.  If you only use one platfor then use a JNI approach.

Now please stop moaning.  :-)

@diroussel2:

it is all the same... the abstract word for local volume, virtual volume,
network volume (share), temp fs, or a compact flash card on a mobile device
ist "storage" or "volume"...

File.listRoots() is still there an works great (sometimes)...
is it an anachronism?! or is it still the java way of platform
independence java stands for?!

so, if you say if someone only use one platform, why he/she should use java?

all mentioned storage types above have things in common... a size, a type,
readable/writeable flags... and they are all storage types (sometimes calles
volume).

the ability to guess the size of a storage device (or a root) is - in an
abstract viewpoint - the same... particularly in a platform-independant way.

ps if on your mobile device is no disk, File.listRoots() should return an 
empty array... and so there is no requirement to guess the size of a non
existing storage device...

moan...

If I have a file:

File f = new File("/usr/shared/");

All most people really want is a method - f.getAvailableSpace() that tells how much space there appears to be in the path indicated, or returns -1 if it can't determine it.  This is "good enough" for the 90% case.

When is J2SE 1.6 due out?

-G

Nine (9) years from identification of need to projected resolution.  Now that is operating on internet time! 

hurray!

"A simple method or two for determining free disk space will be added to the
java.io.File class in Mustang, which is scheduled to ship in mid-2006"

in 1.5 years from now we have two "simple" mehtods for determining free disk space... after only nine years of evaluation!

but... the bug/rfe was reported against  1.3 , 1.4 , 1.1.1 , 1.1.3 , 1.2.1 , 1.3.1 , 1.4.1 , 1.4.2 , kestrel-beta and planned for tiger... and now it is "planned" for mustang... it's time to bet... 

I bet SUN will do the right thing and put this into Mustang.  I'd like it if it saw it's way into the next interrim release of JDK 1.5 - how about it SUN?

http://forums.java.net/jive/thread.jspa?messageID=12277&tstart=0#12277

They are not in the latest build of Mustang... Sun, I am getting worried again....

HOORAY!!!!
Happy belated Birthday To You!
Dear 4057701, I am sorry I missed your birthday.  
4057701 is 8 YEARS OLD today!

Why is this closed when it's not really fixed?  It's not in any builds of 1.5 that I've seen.  And it's been a couple of months since March 1, 2005. 3 to be percise...

It is marked closed - fixed because it has been fixed for Mustang (JDK v1.6)

[by pi10t]

hi!

if you don't want to wait Java 6 you may use Jakarta Project Commons IO library. It provides one class with the function of retrieving the free space on a disk.

http://jakarta.apache.org/commons/io/description.html

BTW: Where/when is the "Sun has fixed the bug after only nine years" party? 

This is great, but it would be more useful if there was also a File.getSpaceUsedByThisFile() function. Compressed filesystems, filesystems with varying block sizes, etc.

amphibian - Geez, some people will complain even if you hang em with a new rope!