File System metadata
elharo at metalab.unc.edu
Mon May 26 18:21:22 PDT 2008
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
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
>> 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!
More information about the nio-discuss