NIO feedback

[John Hendrikx]

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?  :)
>> - After aborting a Copy by returning false, I still get several 
>> feedback calls (10+ on large files) with constant 'bytetransferred' 
>> values.  I assume this is due to the deletion occuring.  I keep 
>> returning "false" for these, don't know what would happen if I 
>> "change" my mind so to speak :)
> The cancellation is done cooperatively (for feasibility reasons) and 
> might not be instantaneous. Also, as you noted, it does attempt to 
> recover and remove the target if partially created. The copyTo method 
> does not complete until this is done and progress events will continue 
> to be reported. Another approach would have been to discontinue events 
> after "false" has been returned.
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.

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.

I will find time to test this under Linux soon as well.

Thanks,
--John