More NIO feedback
hjohn at xs4all.nl
Mon Nov 2 02:23:01 PST 2009
Alan Bateman wrote:
>> 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.
Ok, I can test these for Windows/Linux if they make it in.
>> 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
It's purely a way to help the user to get a file deleted. Telling the
user that Access is denied could mean many things, ranging from lack of
permissions, to the file being in use to it simply being read-only.
Basically, I'm trying to give better feedback, and in the simple cases I
want to try to "fix" the problem (like clearing the read-only flag).
It's like Explorer telling you: "File_01 is read-only, do you want to
remove it anyway?" -- if you confirm, it makes the file deletable (in
this case just clears the read-only flag) and deletes it.
I realize though that what I'm asking is very specific, and the reason
I'm mentioning it is just to get some feedback as well. From what it
looks like though I will try and just handle the simple cases:
For DOS clear read only flag if set and try again (which may mean I need
to set the flag again if it still fails to avoid making a mess of things).
For Posix, see if I can set Owner Write flag (if the user is the owner),
and maybe something similar for groups (although I don't think I can
find out what groups a user belongs to).
For ACL's... well that gets even more complicated, so I guess those will
need to be dealt with by the user.
It would be good though if I could distinguish between a temporary
condition (File is in use) and a more permanent condition (lack of
>> 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.
Ok, I was hoping it would be possible to find out this part atleast.
Although there's no guarantee any operation will succeed at all of
course, just trying the creation of a symbolic link and catching the
resulting exception will have to do for now.
> 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.
I suppose this is near impossible, especially charset and name
limitations can get very tricky. Long ago I wrote my own filesystem,
and if I would have to give you its limitations it would be something like:
- case sensitive or case preserving depending on format parameters
- max name length, 255 bytes (all bytes allowed except '/', ':' and
'\0'), fail when length is exceeded
- max file length, 2^32 - 1 bytes
- max volume size: 1 TB, with block size of 512 bytes, more with larger
- charset: none, raw bytes, see limitation above
The only one of these that really is annoying is when names get
truncated -- it would mean the system just created a file with some
name, but then would be unable to locate it again as the name is
truncated in some unknown way :)
As for sparse file creation, it may not be very useful to know about
this. NIO already ignores the SPARSE option when it is not supported,
which should work fine.
More information about the nio-dev