NIO feedback

[Alan Bateman]

John Hendrikx wrote:
> 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) ?
Yes, that's right. A provider/FileSystem implementation supports a set 
of views but a specific underlying file system/volume might not support 
all of them. A simple example to explain this is where you are on 
Windows and some volumes are NTFS and others are FAT32. If a FileStore 
represents one of the NTFS volumes then it will return true if you ask 
it if supports AclFileAttributeView and UserDefinedFileAttributeView. 
Ask a FileStore representing a FAT32 volume if it supports these view 
and it will return "false". 

> 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.
There isn't a "framework" for doing your own file-copy. The assumption 
is that the copyTo defines copy options to support most needs and the 
provider can support additional provider-specific options where 
required. So this means you need to copy the attributes in a loop with 
code like this:

FileStore sourceStore = source.getFileStore();
FileStore targetStore = target.getFileStore();
for (String view: source.getFileSystem().supportedFileAttributeViews()) {
    if (sourceStore.supportsFileAttributeView(view) &&
        targetStore.supportsFileAttributeView(view))
    {
        Map<String,?> attrs = source.readAttributes(view + ":*");
        for (Map.Entry<String,?> attr: attrs.entrySet()) 
{                   
            try {
                target.setAttribute(view + ":" + attr.getKey(), 
attr.getValue());
            } catch (UnsupportedOperationException x) { }
        }               
    }
}

This is clearly not very efficient in that it will copy some attributes 
more than once (because attribute views can extend or overlap with other 
views) but its probably not too bad because most of the time will be 
spent copying the file contents.

In any case, I'll create a bug for tracking progress. The other one that 
has come up is cancellation (our implementation has support for this 
already). Another one is the ability to be selective as to which 
attributes are copied and to indicate if the method should fail/continue 
if specific attributes cannot be copied (our implementation has this 
capability but it isn't exposed as a CopyOption).

As regards the newByteChannel method (and other methods that allow 
initial attributes to be specified as an array of FileAttributes). The 
use-case for this is file permissions and other security attributes 
(including ACLs) that you want to set when creating the file to avoid 
the timing window that would arise if you created the file and set the 
permissions afterwards.  In other words, it's for security use-cases and 
is not intended as a way to set all the initial attributes (as that is 
just not feasible). Note that FileAttribute just encapsulates a 
name/value pair and you need to eliminate it in order to provider an 
instance to the newByteChannel method. The 
PosixFilePermissions.asFileAttribute method is just for the common-case 
where you want to set the file permissions when creating a file.

Hope this helps,

-Alan.