File System metadata

[Alan Bateman]

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.

-Alan.