Many Thanks for identifying this, romaerzhuk. [sorry, don't know your name, I wish I did :)]
I will fix it by the next release.
Just wanted to add an FYI here...
One basic premise when XADisk is used to interact with a set of files is that, (at a broad level) no other software is simultaneously working over the same set of files. If someone else is also accessing those files which are being worked on by XADisk, (say XADisk delete operation is going on), the application runs into the risk of inconsistency.
When XADisk finds that it is not able to do certain operations (say delete a file, because someone else is writing to it), it makes a guess that someone else is simultaneously tempering with the same file, and disables itself from doing any other operation; applications will then start receiving XASystemNoMoreAvailableException.
Now, the above copyFile code is one such place where, if XADisk receives an exception, it is very likely that someone else doing something, and with current implementation, XADisk will call it "end of the world" and will disable itself. In practice, this would require a more serious remedy by the application administrator. But I agree that doing channel.close() is always better, even in these cases.