NIO feedback

[Alan Bateman]

John Hendrikx wrote:
> Alan Bateman wrote:
>>> - Sometimes the feedback has the same values for several calls in a 
>>> row (due to some OS filesystem contention I'm pretty sure).  This is 
>>> good as it allows me to abort at any time.
>> Right, this is likely wait for I/O or the network (or in theory a 
>> sampling glitch as the transfer progress is sampled without 
>> synchronization - if an out-of-range value is sampled then it is 
>> dropped and the previous "good" value is reported to the progress 
>> method).
> You mean a long is read without synchronization?  :)
Yep - it's just a prototype and there isn't any synchronization between 
the native code and the thread that is sampling and reporting events 
(the sampler simply checks that the value hasn't decreased and is in 
range so in theory it might jump forward more that it should - probably 
not a big deal for this usage).

:
> Something I forgot to mention, the cancellation results in a 
> FileSystemException being thrown.  I think a more specific exception 
> or just a true/false return might be helpful.  Currently the caller 
> code just catches this exception, and then checks if it was an abort 
> that caused it (in which case it is ignored) and otherwise rethrows it.
> I can't however really be 100% sure if it was an abort (ie, whether 
> the abort triggered from the callback was actually processed) or if 
> some other kind of abnormal termination occured.
An exception during recovery doesn't suppress the original abort/cancel 
exception but a more specific exception would make this clearer.

>
> I gave the discontinuing of the events after "false" has been returned 
> some more thought, and I think it is probably better to keep sending 
> events so even during the clean-up phase it is possible to give 
> feedback.  My own specific implementation doesn't require it, but 
> other implementations may find it useful.
>
> Another thing I found while I was testing this code is that it doesn't 
> eliminate the need for a function to copy attributes.  Even though 
> copyTo can do this for files, I still need a custom implementation for 
> softlinks and directories (unless of course, copyTo also works for 
> these kinds of objects... I'll admit that I haven't even considered 
> testing this yet, but the javadoc seems to indicate it isn't 
> allowed).  A suggestion could be to make copyTo work with 
> directories/softlinks as well (not recursively), or expose a function 
> to copy attributes.
The copyTo method follow sym links by default but it will copy a sym 
link if you specify the NOFOLLOW_LINKS option. The file attributes of 
sym links aren't usually interesting but our implementation does 
whatever is appropriate for the platform. The copyTo method will copy a 
directory too.

That's for playing with this.

-Alan.