File System metadata
Alan.Bateman at Sun.COM
Tue May 27 02:18:10 PDT 2008
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
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
More information about the nio-discuss