Support of named attributes in jdk7

[Jean-Pierre André]

Hi Alan,

Alan Bateman wrote:
>
> Jean-Pierre André wrote:
>> Hi,
>>
>> I am working with the ntfs-3g project, aiming at providing NTFS
>> storage for multiple OS (Linux, MacOSX, Solaris, etc.), and I am
>> currently fulfilling the development of extended attributes.
>>
>> A specific concern for us, as pluggable storage devices tend now to be
>> formatted as NTFS off the box, is that the files created on a platform
>> can be directly used when the plugged into another platform, even
>> of a different type.
>>
>> As jdk7 is apparently extending the io class to support named
>> attributes, we would like our implementation to be such that a Java
>> application running on any platform and using NTFS could process
>> the data written by the same application on another platform.
>>
>> The main problem is to comply with the rules for naming the attributes
>> on each platform, and we think these naming rules should be hidden
>> from the Java programmer. On Linux specifically, the prefix "user."
>> should not be apparent.
>>
>> As a consequence, we (at ntfs-3g) have to make adaptations so that
>> the extended attributes are stored the same way on NTFS from either
>> Windows, Linux, Solaris or Mac OS X. Currently we map the extended
>> attributes to alternative data streams.
>>
>> Attached is a chart trying to explain this, and we would like to know
>> whether jdk7 supports a similar view.
>>
>> Home page of the ntfs-3g project : http://www.ntfs-3g.org
>> Implementation of extended attributes :
>> http://pagesperso-orange.fr/b.andre/extend-attr.html
>>
>> Regards
>>
>> Jean-Pierre
> I think this is reasonable and arguably a poor implementation choice 
> on my part to have required the namespace be included in the name. 
> With that fixed then the translations work as per the interface 
> boundaries in your slide.
>
> One thing that isn't clear to me about ntfs-3g is the conversion 
> to/from Unicode for both file names and extended attribute names when 
> accessing NTFS. The extended attribute names in our API are provided 
> by the application as Unicode strings and so are encoded to bytes for 
> the *xattr calls.  I assume ntfs-3g then encodes these bytes to 
> UTF-16/UCS-2 that NTFS uses. Can you say more about this? (just 
> wondering if round-trips are going to be a problem).

Yes, of course the names have to be translated when needed.
We have a long tradition of converting UTF8 to and from UTF16,
including in special situations as needed for Hangul. Translating
attribute names will of course be done as file names are.

On the contrary, we do not interpretation of the attribute value.
We expect the application to deal with it in a consistent way, just
like when putting data inside a file.

In the Xdd.java example, the value was a string, and I had no
problem, but there surely would have been if the Windows version
had put UTF16 and the Linux one had interpreted it as UTF8.
You must have defined a consistent representation of the value.

Regards

Jean-Pierre







>
> -Alan.
>
>

-- 
JP André
email jean-pierre.andre at wanadoo.fr