NIO feedback

[Alan Bateman]

John Hendrikx wrote:
> :
>
> Reading Attributes:
>
> I found there is no way to just get all attributes that a filesystem 
> can provide, or find out what the "most specific" AttributeView is 
> that a filesystem provides.  Something like:
>
>  path.getAttributes("*:*");
>
> is not allowed.  
I think this is what you are looking for:

Path file = ...
FileStore store = file.getFileStore();       
for (String view: file.getFileSystem().supportedFileAttributeViews()) {
  if (store.supportsFileAttributeView(view)) {
    Map<String,?> attrs = file.readAttributes(view + ":*");
  }
}

This iterates over the supported views and queries the FileStore (the 
underlying file system in Unix/Linux terms) to see if it supported. If 
supported then it reads all attributes that the view supports.  As 
should become clear, the exact list of attributes depends on the 
underlying file system and so can/will vary if you have different types 
of file system mounted.

> :
>
> 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).

>
> 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??).

>
> ACL:
>
> I cannot read ACL's at all under Linux (ext3), I get an 
> UnsupportedOperationException.  I hope support for this is still 
> forthcoming.
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.

>
> copyTo/moveTo:
>
> These are not very useful for me, I'd like to give feedback during 
> this process (progress indicator).
Our default provider doesn't have any hooks or notifications for this. 
It's definitely something that a "desktop" provider would need to support.

> Also, I really miss a rename function on the Path class.  Currently it 
> is important for my application to know when a moveTo will simply be a 
> quick rename, or when it involves actually doing a copy (in which case 
> I want to do it manually to give progress information).   I have to 
> compare FileStores to see if it will be a copy or just a plain rename 
> (not sure how much of a guarantee that is though).  The ATOMIC_MOVE 
> option is unclear whether this will mean "just a rename" and/or "yes 
> we'll do an-hour-long-copy transactionally if the filesystem supports 
> it".
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);

-Alan.