File System metadata

[Elliotte Harold]

Alan Bateman wrote:
> 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?
> 

The first thing that comes to mind is pretty much everything on Mac OS X.

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.

The fifth are a few standard NTFS attributes like compress that you seem 
to have missed (unless I just missed them in the JavaDoc).

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 advance.

> 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.

There's no need for compile time type safety here. You can program with 
the knowledge of which attributes you expect to find in a file system 
without needing to have everything predefined in a class at compile time.

Let me reemphasize: I want to be able to write code that inspects the 
local platform and behaves accordingly without using any platform 
dependent classes. I do not want to have to use any Apple specific 
classes just to read the Mac creator code when my program is running on 
the Mac (for example). Instead I want to to be able to simply ask for 
the relevant attribute and get it if it's available, and get null if 
it's not. I don't want to bundle extra classes with my app just to do 
this. The local, implementation dependent classes in the local VM will 
know which attributes they do and don't support. That should be enough.


>> 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.

My point was a though experiment. Suppose POSIX attributes were not 
supported by many file systems, and were not bundled with the JDK so you 
couldn't rely on their presence across platforms. (That is remove every 
method and class from java.nio.file with the word POSIX in its name.)

Now suppose you happen to be the developer working in a POSIX VM that 
provides impl classes that support POSIX attributes. You need to write a 
program that takes advantage of POSIX attributes when available, but 
doesn't fall over and die when it runs on a non-POSIX platform. Would 
you be comfortable using the java.nio.file API?

My claim is that you would be very uncomfortable. This is exactly how 
developers writing Swing applications that behave natively on the Mac 
have had to work for years, and it is doable but very painful and lot of 
work.

Now this cross-platform pain is going to be extended to anyone working 
on a file system (including custom virtual file systems) that is not 
bundled with the JDK.

I think that some basic redesigns of the attributes mechanism so that 
much less detail and foreknowledge was baked into the method and class 
names at compile time would make it all much more flexible and far less 
painful.

>> 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.

No one's saying you'd write code without knowledge of the definitions. 
You'd still know what getAttributes().get("readonly") was likely to 
return. You'd just encode that foreknowledge in the method argument 
instead of the method name.

-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/