More NIO feedback
Alan.Bateman at Sun.COM
Sun Nov 1 12:58:49 PST 2009
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
> 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"
> 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.
More information about the nio-dev