A new filesystem interface that supports bulk access to file attributes
(including MIME content types), escape to filesystem-specific APIs, and a
service-provider interface for pluggable filesystem implementations.  This
API will work more consistently across platforms, will make it easier to
write programs that gracefully handle the failure of filesystem operations,
will provide more efficient access to a larger set of file attributes, will
allow developers of sophisticated applications to take advantage of
platform-specific features when absolutely necessary, and will allow
support for non-native filesystems, such as network filesystems, to be
"plugged in" to the platform.
  xxxxx@xxxxx   10/20/04 00:31 GMT

N/A

(updated Feb 10, 2006)

JSR-203 (http://jcp.org/en/jsr/detail?id=203) is currently working on a new file system interface that will address the items listed in the description of this bug. Our goal with this JSR is to deliver in good time to be included in Dolphin (Java SE 7) - this assumes of course that it will be approved as a component JSR in Dolphin.
Posted Date : 2006-02-10 10:21:54.0

"JSR-051" here means
http://jcp.org/jsr/detail/051.jsp

Well JDK1.4 is here in beta form, and the section from JSR
51 which was meant to address this stuff seems to have
dropped off the face of the planet.

What is happening?

Well. This is not coming in JDK 1.4 (Merlin).

See the proposed final draft of JSR 59 for details:

"[...] • 4313886 “improved IO exceptions”. See the 
following item.
• 4313887 “improved filesystem interface”. We are 
reluctantly dropping these two I/O features due to resource 
constraints. It has become clear that we are not going to 
be able to complete the full set of new I/O features. It 
appears more important to focus on completing other I/O 
features, notably asynchronous I/O and fast buffered I/O.
[...]"

It would be REALLY nice to have an INTERFACE for the
FileSystem or at least an abstract class that didn't call
Natives directly!

The work around is as follows. It works for me on AIX.

Assume, there are two files (/opt/a.txt, /opt/b.txt). Here "b.txt" is a symbolic link to "a.txt".
File system listing shows (b.txt -> a.txt).

File f = new File("b.txt");
System.out.println("Canonical : "+f.getCanonicalPath());
System.out.println("Absolute : "+f.getAbsolutePath()); 

Output :

Canonical : a.txt
Absolute : b.txt

So, when the absolute path is not equal to canonical path, it is a symbolic link. Absolute path is the link 
itself and the canonical path is the original file.

If there is a symbolic link (c.txt -> b.txt -> a.txt), then for 'c.txt', absolute path is 'c.txt' and canonical 
path is 'a.txt'. So, you can use JNI and issue a "readLink" system call to get 'b.txt' and so on till you reach 
'a.txt', which is the end of the link chain.

Probably implementation of File.setReadOnly() that will 
invert ReadOnly attribute can solve some of problms ? Seems 
like it doesn't require much efforts to implement.

Please consider including a facility for registering
listeners on file changes, and for pluggable filesystem
implementations to fire changes. The default Win32 impl
could proxy to the native file notifications. The default
Unix impl could use the SGI-FAM library where available.

Sincerely I didn't know about the problem, and I was hoping 
that when creating a ex: FilePermission( 
myPath, "read,write" ); I will have my files updated. It seems 
security managing doesn't work on concurrent VM, you say no 
one will touch this, and you have it changed inside your hat. 
This problem implies a 'necessity' of what said jglick (above).

Agree 100% with what jglick said. Imperative that a true blue 
FileSystem Interface along with notification mechanism of file 
changes.

And please don't forget the RFEs 4285835 and the six years 
(!!!) old RFE 4057701 - for example in a java.io.Volume 
pendant to java.io.File

We really must have a way to scan 100,000 files in a
directory without loading all the file names into memory at
once.  It is rediculous to have to tell your customers that
Java can't scale to enterprise machines because of simple
problems that are so easy to fix...

Something like:

import java.util.*;
import java.io.*;

public interface FileListAccess {
	public FileIterator contents( String dir, FilenameFilter
filt ) throws IOException;
	public FileIterator contents( String dir ) throws IOException;
}

public interface FileIterator {
	public Object next() throws IOException;
	public boolean hasNext() throws IOException;
}

there has to be something somewhere to get started...

More filesystems (e.g., ext3, reiserfs) are including
Extended Attributes. It would be nice to have a standard
Java interface to them, esp. Access Control Lists.
I thought Tiger was 1.5, but in the 1.5 docs available on
the web so far, I don't see any mention of File
enhancements. What's the current timeline?

An important missing feature for me is "boolean java.io.File.setHidden(boolean)". Maybe it could only ever return true on Windows (on UNIX, renameTo with a dot in front of the filename is sufficient - and I don't mind checking which platform I'm on for this very platform-dependent feature).

When is this enhancement scheduled? I see the evaluation says Tiger release but the bug report is against tiger as well.

The following expression DOES NOT tell you that file is a link, it tells you that there is a link somewhere in the file's ancestry.
!file.getAbsolutePath().equals(f.getCanonicalPath())

And since all links get resolved by the Canonical methods you cannot identify a link's immediate target, e.g. for the situation where a->b->c it is impossible to tell that b is involved with java calls alone.

Consider this a request for File.getSymbolicLinkPath() that returns null for non symbolic links and the immediate target otherwise.

Please consider adding a java.io.File.setHidden(boolean) method as part of this enhancement. See also bug ID 4267530.

File.getSymbolicLinkPath() or getLinkTargetPath() or at least isSymbolicLink() method will be very, very usefull. 

In my application I forced to call "ls" program with "exec" to detect whether file is a symbolic link or not (after figuring out that canonical path is not the same as absolute one [symlink], or that exists() returns "false" and file is listed in parent directory listFiles() method resuts). As you could imagine - it is works very slow making whole application work very slow on Linux/OS X.

Additionally above algorithm doesn't work when canonPathCache is enabled (that is default) - so, I'm forced to disable this cache - this makes program work even more slowly.

I'm very upset this feature is not in JDK1.6 yet :(

setHidden(boolean) on UNIX should renameTo() with or without a prefix of '.' -- no need to always make it return false. This way it'll be perfectly cross-platform on UNIX and Windows.

It seems that many of the commentors are requesting features that are in many cases not available on all platforms. This being the case, why don't they just write their own class with native implementions (or using the System.exec) of the methods for the OS they are targeting, and then on the others they can noop these.

If you are doing platform specific stuffs there are a multitude of ways to handle it. Should the JDK support some of these things, probably. Should it be the ultimate priority, probably not (when other work-arounds exist).

You say it: Workarounds.

The most platforms  have the ability to listen for filesystem changes/changing media, support api calls to iterate through a filesystem, they support network filesystems (cifs, nfs, ...),  they support the concept of links (i. e. soft links) or simply can identify those special files (links, network shares etc.) to hide them (if support is not available). but where are these apis in io/nio?!

Java is called a platform-idependant language - so why I must use workarounds for simple standard tasks. I/O is a basic concept of every OS... an Java is a kind of virtual OS.

What's the status of this? The last note under "Evaluation" above is dated Feb 10, 2006.

One thing that a new IO system should do is make MappedByteBuffers useful. They're currently unusable because there is a limit of 2 Gb on the total amount of file space that can be mapped. For large databases, this is a show stopper. What would be better is to rely to allow mapping larger files, and then rely on operating system caching to determine what part of the file is actually in memory and what part must be fetched from disk.

The early draft review specification for JSR-203 was submitted recently. The spec addresses most of the issues discussed here. I have a blog entry with links to the spec and other material here:
http://blogs.sun.com/alanb/entry/nio2_edr_available

Seems like latest builds are here in case anyone wants to try out JSR 203:

http://download.java.net/jdk7/jsr203/binaries/

and javadocs:

http://openjdk.java.net/projects/nio/javadoc/index.html