File System metadata

[Alan Bateman]

Elliotte Harold wrote:
> I'm still working through the details, but the current implementation 
> of FileSystem attributes seems way too limited. It's basically giving 
> us what we have already, just in a new form.
The attributes defined by the various views in the attribute package 
provide access to significantly more meta-data than is possible with the 
File class today. Furthermore, an implementation can support additional 
views beyond those defined in that package -- ie: a provider is not 
limited to the attribute views defined in the attribute package. Another 
point is that one of our goals with the new API is to provide bulk 
access to file attributes - essentially a stat-like API because too 
often we see performance issues with applications that need to access 
several file attributes of the same file at around the same time.

>
> I was really hoping for a system that would allow for arbitrary 
> properties on files without tieing the API to any one operating 
> system. For instance,
>
> int permissions = file.getIntProperty("permissions");
> boolean readonly = file.getBooleanProperty("readonly"):
>
> We can certainly debate exactly what sort of syntax for such generic 
> metadata is appropriate. Java's strong typing makes this really hard 
> to design elegantly. Perhaps they should all just be Object. Perhaps 
> they shoudl just be strings. Maybe we need methods that return default 
> values and maybe we don't. Those details can be worked out.
There's nothing to prevent us adding something that would provide 
reflective access but if you want to do something reasonable with the 
attribute values then you'll need to know something about their types 
and semantics. Taking your example of "permissions". In that case, 
you'll need the permissions attribute specified somewhere in order to 
interpret it. If I want to change the group permissions then I'll need 
to know which bit to toggle for example. It gets more fun with more 
complicated attributes such as access control lists. If the ACL is 
returned to me as a String then it will have to encode the list of 
entries with each entry further encoding the type, the identity, 
permissions, etc.  As I hope I can convince you, the attributes needs to 
be defined somewhere to be usable by portable applications.

>
> Nonetheless the current approach of supporting only POSIX and DOS 
> attributes, and then naming those attributes explicitly seems very 
> rigid and not very useful. What about NTFS and Mac OS X attributes? 
> and whatever comes next? What about virtual file systems based on HTTP 
> or a source code control system?
In the zipfs sample code you'll see an example of this in action. It 
defines ZipFileAttributeView and JarFileAttributeView that provide 
access to zip/JAR entry specific attributes.

>
> I think a filesystem should be able to provide whichever attributes 
> make sense to it, and these should be queryable through a standard 
> interface.  Perhaps we can still have Basic and Space attributes, but 
> we need a much more generic system that does not attempt to enumerate 
> all possible attributes up front.
>
The granularity of the support is at the level of a set or group of 
attributes rather than individual attributes. To that end, the 
FileSystem#getFileAttributeViews is the method to enumerate the 
supported FileAttributeViews supported by the FileSystem. You can also 
ask an underlying FileStore if it supports a given view by invoking the 
supportsFileAttributeView method.  An implementation is minimally 
required to support BaiscFileAttributeView and may support others 
(including provider/implementation specific FileAttributeView types that 
aren't defined by the attribute package).

-Alan.