OpenOption v. FileAttribute

[Salter, Thomas A]

I think you've answered my questions.  Thanks.

My reference to character encoding was supposed to be easy-to-understand example, but turns out to be bad example since the information is already conveyed by the Charset.

I didn't mention the file system since I didn't expect any one reading this to be familiar with the Unisys MCP operating system (also known as ClearPath, Libra and. Borroughs A-Series).  Anyway, the file system support tons of attributes, a few of which make sense in the Java environment.


From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM]
Sent: Friday, January 22, 2010 12:40 PM
To: Salter, Thomas A
Cc: nio-discuss at openjdk.java.net
Subject: Re: OpenOption v. FileAttribute


On 20 Jan 2010, at 23:55, Salter, Thomas A wrote:


What's the intended distinction between OpenOption and FileAttribute?  It seems like most functions that take OpenOption also support an overload with FileAttribute, except for Path.newOutputStream.

It almost looks like OpenOption was intended to be for features that only apply to the processing of the file and FileAttribute was to specify permanent characteristics of the file.  StandardOpenOption.sparse would seem to be an exception.

That's right - open options specify how is opened and/or created. The FileAttribute[] parameter is to specify initial attributes/meta data when creating a file. The primary use-case is security attributes (permissions or an ACL) to eliminate the attack window that would otherwise arise if the file creation and setting the security attributes were separate operations. It could be used for setting the initial value of other file attributes/meta data but it's usually not as interesting.

The SPARSE open option is a platform independent "hint" when creating a file. Windows does expose it as an attribute, which might be why you mentioned this one, but there is no assumption in this API how it might be implemented or exposed.




FileChannel.open (and similar functions) explicitly mention state "An implementation may also support additional options." under the OpenOptions, but don't make the same statement for FileAttribute.  Isn't the intention those can be extended also?

Yes, and maybe we need to re-examine some of the wording here to make this clearer.




Suppose my file system has a way to save the character encoding of a text file (ASCII, EBCDIC, Unicode).  Should setting that be mapped to an OpenOption or a FileAttribute?


In the API, the file contents are just a stream of bytes. You use a CharsetEncoder/Decoder to convert to/from chars. I don't anything about the file system you are thinking of, but it sounds like the charset encoding is an attribute might map to the appropriate Charset when reading the file - is that right?

-Alan

-Alan.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20100122/0a65d8c3/attachment-0001.html