More NIO feedback

[John Hendrikx]

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" 
>> 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?
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 
permissions).
>> 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 
blocksizes
- 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.

--John