Alan.Bateman at Sun.COM
Mon Oct 6 07:50:12 PDT 2008
Elliotte Harold wrote:
> Well, not everywhere. :-) However I do wonder about the use of
> ByteBuffers in what amount to maps such as NamedAttributeView.
> I think named attributes need to be reduced to a simple String name
> and an Object or String (probably Object) value. ByteBuffers simply
> should not be in the picture here. I guess you have ByteBuffers on the
> brain because of all the other work you're doing with them, but
> they're not a common or comfortable API for this sort of work. Nor
> are they necessary. I think if you treat the NamedAttributeView as a
> map, it will be much simpler, cleaner, and more effective.
I suspect we have a mis-understanding here. The NamedAttributeView
provides a view of a file's "named attributes" which are typically used
to store meta data that is not meaningful to the file system -- ie: this
is not your usual file size, time stamps, file permissions, etc. This is
application defined meta-data that can only be treated as binary blobs
by the file system and API. The blobs are named and the read/write
methods are used for transferring the bits (hence the buffers). The
terminology varies by operating system and file system but think
extended attributes or named streams. In our implementation it maps to
NTFS Alternative Data Streams, ext3 extended attributes, or zfs extended
attributes. In the samples directory you will find the Xdd sample that
may be useful to try.
As regards the javadoc you cited - the FileAttributeViews provide for
both typesafe and "dynamic access" to the attributes that they support.
For dynamic access, which I think is what you are looking for, you use
the Attributes class and the getAttribute/setAttribute/readAttributes
methods to read or update the attributes you require. The readAttributes
methods returns a map of the requested attributes.
I hope this helps,
More information about the nio-discuss