NIO feedback

[John Hendrikx]

Alan Bateman wrote:
> John Hendrikx wrote:
>>
>> It results in [basic, owner, user, dos, unix, posix] which confuses 
>> me.  Why is "dos" in there?  So I tried querying it.  I get a 
>> FileSystemException (/temp: Operation not supported).
>>
> The "dos" view is supported when you have extended attributes enabled. 
> I think in one of your other mails you mentioned that you were using 
> Samba and if you have this configured to store dos attributes then you 
> can you use the dos view to read/write the DOS attributes that the 
> clients see. The "Operation not supported" is probably because it's 
> not mounted with the user_xattr mount (use "mount -o 
> remount,user_xattr ..." to resolve that). Once the file system is 
> mounted with this option then supportsFileAttributeView("dos") will 
> return true (I assume it is returning false now).
It was not a Samba mount in this case, it was an ext3 filesystem mounted 
on /raid1 -- I have not checked what FileStore's 
supportsFileAttributeView will return, but if I understand you correctly 
it is possible that FileSystem's supportedFileAttributeViews() can 
return views which are in turn returning false for FileStore's  
supportsFileAttributeView(xxx) ?

I will check this when I get home.

>
>>
>> Writing Attributes:
>>
>> Above I managed to read the attributes in some fashion.  Now I want 
>> to set them.  I discovered some of the attributes (like "attributes" 
>> in dos) are read only.  So instead I query 
>> "readOnly,hidden,archive,system", not really optimal.  Especially 
>> because I cannot find a way to set multiple attributes at once.  I'm 
>> left with:
>>
>>  for(String key : attributes.keySet()) {
>>     destinationPath.setAttribute(type + ":" + key, 
>> attributes.get(key), LinkOption.NOFOLLOW_LINKS);
>>  }
>>
>> Again, is there a better way?  What I'm trying to achieve is to 
>> simply make an exact copy of a file, including most attributes, 
>> lastModifiedTime, ACL's and owner/group information.  Setting half a 
>> dozen attributes in a row seems akward.
> The simplest way to do this is:
>   source.copyTo(target, COPY_ATTRIBUTES);
> This will attempt to copy all the attributes from the source to the 
> target file (including basic attributes, permissions, DOS, ACLs, 
> extended attributes, etc.).
>
> (I might not be understanding the full context here and maybe you are 
> rolling your own file copy??).
I'm rolling my own copy to be able to give progress information and was 
looking for a way to make a nearly exact copy.  I did not see a more 
framework supported way of doing it (although you gave a hint below 
about a desktop provider).

I'm using Path's newByteChannel(Set<? extends OpenOption> options, 
FileAttribute<?>... attrs) for the copy, however I saw no good way of 
providing all the FileAttribute's.  There seems to be only one method 
that even creates these FileAttribute instances, and it only does so for 
posix permissions.
>
> This API is based on the NFSv4 ACL model. I don't think any of the 
> Linux distributions ship with support for this yet. When they do then 
> we can add support for the "acl" view.
Yeah, it doesn't look like the support for these is present in the 
latest kernel's yet.
> The assumption has been that source.moveTo(target) or 
> source.moveTo(target, REPLACE_EXISTING) will satisfy most needs. The 
> ATOMIC_MOVE option is the advanced option but it's essentially a 
> rename. The difference is that a "simple rename" can check if the 
> target file exists and so is not atomic. We have an RFE for this:
>  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6878283
>
> In the mean-time, you can do this:
>  if (target.notExists()) source.moveTo(target, ATOMIC_MOVE);
The RFE would solve this.  My only concern was that highly advanced 
implementations might try to do the move wrapped in a transaction 
somehow (which would satisfy the ATOMIC_MOVE requirement) but still take 
a long time as they're doing a full copy in the background.

Thanks,
John