More NIO feedback

[Alan Bateman]

John Hendrikx wrote:
> As I'm working with NIO2 pretty extensively, here's some more feedback 
> on the framework:
Thanks for taking time to write up the issues/needs that you are running 
into.

>
> 1) Other than parsing exception message text, there's no way to 
> distinguish a "disk full" condition and other FileSystemExceptions.  
> Disk Full conditions are something a user can solve in the background 
> allowing the offending operation to be retried and so I would like to 
> inform the user of this condition in a more specific way.
This one is overdue (see 4533668) and we should just do it - it's just 
needs a bit of work to test each of the operations (writing, creation, 
copying, ...) on each of the platforms.
>
> 2) Will there be any new way of obtaining an icon for a Path?  It is a 
> kind of Attribute.  Currently obtaining these involves using 
> javax.swing.filechooser.FileSystemView.  This works well for Windows.  
> For Linux however it is very bland, resulting in the need to customize 
> this.  Files.probeContentType's mimetype is already a big help for 
> doing this manually though.
A desktop icon isn't something that a file system knows about. Icons may 
be stored as files or user-defined/extended attributes but the file 
system or API doesn't have semantic knowledge. As I've mentioned in 
other mails here, a good candidate for a file system provider is a 
"desktop" provider that works with the Windows shell or GNOME file 
system. It could expose icons as attributes, synthesize sym links as 
short cuts, delete files by moving them to a "recycle bin", etc.  In the 
absence of such a provider then the best approximation is to do your own 
mapping from the MIME type to an Icon.

>
> 3) I was having some trouble automagically handling retries of 
> operations that throw AccessDeniedException.  For example, 
> Path.delete() can throw this, and what I'm trying to achieve is to see 
> if the Attributes can be altered in such a way (with the current 
> privileges) that would result in the delete succeeding (a "forced" 
> delete).
>
> This is somewhat harder than I expected, although not impossible.  I'm 
> writing a static class to handle these nasty details.
If operations like delete are failing with "access denied" then it could 
be one of many issues. Is it transient and a retry succeeds if 
re-attempted after some time? If so, and this is Windows, then it might 
suggest you are are trying to delete files that are in use by other 
entities that have the DOS sharing mode explicitly set to disallow 
delete or they have file mapped into memory. A "forceful" delete can't 
do very much here except back-off for a time, retry, and "hope" that the 
other process is done.

On other hand, maybe you asking that the file permissions or ACL be 
changed prior to delete to improve the chance that the file can be deleted?

>
> 4) Related to 3, I'm wondering if there's any way Java could 
> temporarily get higher privileges (like obtaining root privileges by 
> prompting for a password).  Is such a thing possible at all?
I think you might be looking for something like PolicyKit or UAC but 
it's a bit outside the scope of this API (and would cover a lot more 
than access to the file system).

>
> 5) Is there any way to obtain FileStore specific parameters, like:
> - case sensitivity
> - limitations (max name length, max file size)
> - charset
> - soft/hard link support available
> - sparse file creation
Not in the standard API but the attribute support is very extensible by 
providers. At one point we did look at supporting a way to test if a 
FileStore supported symbolic and/or hard links but it's just not 
feasible/reliable when the file system is remote. Case sensitivity is a 
lot more complicated than it might it seem. For example, knowing if a 
file system is case sensitive and/or case preserving isn't sufficient. 
You need to know if the file system is unicode or bytes. If Unicode you 
need to know about normalization and other treatment of characters. NTFS 
is the extreme with a per volume table for case mapping. "Limitations" 
is also complex as it also requires knowing a lot about the underlying 
volume/file system and knowing how it behaves when presented with a file 
name that exceeds a maximum length (does it fail, is it truncated?, 
etc.). As with the sym link capabilities we get into feasibility issues 
when the file system is remote. Is knowing the "sparse file creation" 
useful? I don't think this has been asked for before.

-Alan.