hjohn at xs4all.nl
Mon Oct 26 05:07:00 PDT 2009
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
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.
More information about the nio-dev