File System metadata
Alan.Bateman at Sun.COM
Mon May 26 06:18:20 PDT 2008
Elliotte Harold wrote:
> There are a few extra bits but not as much as I expected. There's a
> lot more that's out there that isn't supported by the current API.
Which file attributes are you specifically thinking about and are they
interesting to main-stream applications?
> My hope that was by supporting arbitrary names and values one could
> write platform specific code without using platform specific classes.
> For example, I want to write a program that uses Mac specific
> attributes when running on a Mac, I'll probably need classes and
> methods that are only available on Apple's VM. This means that not
> only do I have to write platform specific code. I also have to do a
> lot of extra work to allow the same code to compile and run on other
> platforms due to missing classes and methods. Not impossible, of
> course. I do a lot of this already today. A generic file metadata API
> that used only JDK standard classes and methods would be a lot easier
> to configure at runtime.
For the Mac port it should support BasicFileAttributeView,
PosixFileAttributeView, AclFileAttributeView, and NamedAttributeFileView
at least. You are correct that if you want to access/manipulate file
system specific attributes then the classes would need to be present.
Reflective access would help with that but you loose compile time safety.
> These will be second class citizens though. Imagine we removed the
> PosixFileAttributes and DosFileAttributes classes and associated
> methods; and relegated them to optional JDK-vendor specific extensions
> that programmers could not assume the presence of. Would you still be
> satisfied with the functionality that was available?
The reason these attributes views are defined is because the respective
attributes are commonly used or supported by many file systems.
>> 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.
> That's fine. You could of course have a generic getAttributes method
> that returned a map of all the attributes on the file on the given
> file system.
Except there isn't much you can do with them without their definitions.
For example, if the map contains the entry "hfsplus.checkedData" for the
HFS+ specific attribute that is the date/time that the volume was
checked for consistency then you can't interpret the value without
implementation specific specification.
More information about the nio-discuss