File System metadata

[Alan Bateman]

Elliotte Harold wrote:
> :
> The first thing that comes to mind is pretty much everything on Mac OS X.
Nick may want to chime in here but I believe almost everything is 
already covered by the file attributes views that we have included. HFS+ 
does have a number of HFS+ specific attributes but I don't know if many 
non-specialized applications make use of these or even if they are 
accessible to user-mode applications.

>
> The second is version control information for a custom VFS based on a 
> source code control repository.
>
> The third are WebDAV HTTP headers.
>
> The fourth are arbitrary NTFS attributes that can be defined by an 
> application. These can't even be enumerated, or predicted by any 
> compile time library whether written by Sun, me, or Microsoft.
Are you thinking of NTFS extended attributes? I'm not aware that these 
are accessible to user-mode applications. You might be thinking of NTFS 
Alternative Data Streams in which case this is what NamedAttributeView 
uses on that file system.
>
> The fifth are a few standard NTFS attributes like compress that you 
> seem to have missed (unless I just missed them in the JavaDoc).
There are a few other NTFS specific attributes but it's so rare to find 
applications that make use of them that we didn't include a NTFS 
specific attribute view.

>
> The sixth are whatever new standard attributes Microsoft and others 
> add in future versions of their operating systems before you can rev 
> and release a new version of Java to support them.
>
> I see no plausible way we can predict all the likely attributes in 
> advance.
The approach we have taken to date is that each provider is required to 
support BasicFileAttributeView that provides access to a basic set of 
attributes that are common to many file systems. For many applications 
this should be sufficient as they won't care about other attributes. For 
other file attributes then there are choices on how they can be 
supported. The approach we have taken is to allow the provider 
implementor define views of the attributes that it supports. Out of the 
box, the platform can define optional views for common sets of file 
attributes. The provider may define others. As you have observed, this 
means that if you want to access these file system specific attributes 
then you do need to compile against the interface that the provider 
defines. No big deal for an application that targets a specific platform 
or provider but a pain if you are a generic file attribute browser or 
have semantic knowledge about certain file systems that you use when 
running on those file systems. The other approach, which isn't 
incompatible with the first approach, is to provide generic or 
reflective access. At one point we had a prototype file attribute view 
that did exactly that. Okay for simple types but messy for anything more 
complicated. All I can say is that I will check with the group about 
re-visiting this topic but I'm prettry sure we don't want to re-invent 
JNDI :-)

-Alan.