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