Getting started

[Alan Bateman]

Salter, Thomas A wrote:
> Is there any additional documentation on the structure of the NIO2 
> implementation? I've looked at the obvious: Javadocs, the JavaOne 
> presentation and the Open Road article by Elliotte Harold. What I'd 
> like is a liittle more insight into how the implementation classes fit 
> together and the theory behind the user-visible class abstractions.
> Here's a couple of specific questions:
> 1. Is there a way to handle distinct types of disk file structures 
> that support different sets of attributes? For instance, Windows FAT 
> and NTFS partitions have distinct capabilities, but I don't see 
> anything in the code that makes a distinction. So if someone tries to 
> access user-deifined attributes on a FAT disk, does it throw an 
> exception? [This is just an example; I may be wrong about what is 
> supported on FAT disks these days.] It looks like these kinds of 
> capabilities are identified by the FileSystem object, as is the Path 
> syntax and URI. It seems like it would be better if the user should be 
> able to query which attribute sets are available on a given FileStore.
It sounds like you are on Windows, in which case where is FileStore per 
partition/volume. The API allows for the underlying FileStores to have 
different capabilities. The supportsFileAttributeView method allows you 
test if the FileStore supports a given file attribute view. That would 
allow you to test the FAT volume to see if it supports user-defined 
attributes for example. In the FAT and NTFS case you'll see that the 
FileStore representing the FAT volume doesn't support the "xattr" or 
"acl" views whereas the NTFS does. The complete set of supported views 
is returned by the FileSystems#supportedFileAttrivbuteViews method.

> 2. I've seen a reference to how the FileSystem object would let 
> someone import foreign file systems, presumably through mountable 
> devices. Doesn’t this imply that the naming convention for the 
> imported file system would need a distinct URI? It seems more natural 
> to map the imported file system to a drive letter (on Windows). This 
> would require a FileSystems.getFileSystem that accepted a Path 
> parameter, but of course that wouldn't work since Path objects are 
> already associated with a FileSystem. Or, Paths.get(String) could be 
> allowed to determine the appropriate FileSystem by some 
> system-dependent means, but then its Javadoc description would be 
> quite wrong.
When accessing the mounted volumes then you won't need to be concerned 
with URIs. You can use C:\foo or D:\bar as you would in any native 
application. If you want to you URIs then you want (file:///C:/foo and 
file:///D:/bar). If I read your mail correctly then you might be trying 
to thinking there is as FileSystem per volume/partition whereas these 
are concerned to be underlying storage and so each is represented by a 
FileStore.

> 3. Basically, I'm trying to handle two very different and very 
> distinct disk subsystems that are accessed in very different ways, but 
> are unified in a common namespace. With the current Java.io.* classes, 
> we examine the file name and determine how to access the file. 
> Superficially, NIO.2 should let us sort things out at a higher level 
> and have two separate implementations for the different types of disk. 
> It just doesn't quite seem to work out right. Do you have any suggestions?
In the example you pose there is one FileSystem instance 
(FileSystems.getDefault), one namespace, and two FileStores representing 
the two partitions/volumes. I don't see any problem with this mapping.

I hope this helps,

-Alan.