How do I stop Path.copyTo (nio2 method)?

[Fabiano Santa Clara]

I've tried just wrap the transfer in a FutureTask and pass it to an Executor, but the transfer doesn't stop.

[Ninad Kulkarni]

Hi Fabiano,

Welcome to JavaRanch.

Would you give more information because I read your post but could not understand what you want to ask?

Can anybody here focus on this.

[Fabiano Santa Clara]

Hi, Kulkarni.

Ninad Kulkarni wrote:Hi Fabiano,
Welcome to JavaRanch.

^ Thank you!

I'm trying to stop a Path.copyTo operation in my application.

So, I've wrapped the transfer in a FutureTask and pass it to an Executor:

ExecutorService executor = Executors.newCachedThreadPool();
Callable<Object> task = new Callable<Object>() {
	public Object call() throws InterruptedException {
		try {
			return file.toPath().copyTo(target.toPath());
		} catch (IOException e) {
			ex = e;
		}
		return null;
	}
};
Future<Object> future = executor.submit(task);

But, when I call future.cancel(true), the file continues to be copied in file system.

How can I stop a Path.copyTo ?

Thank you.

[Steve Luke]

Good question, but I don't know if you can. The Future.cancel method can only attempt to cancel an action by interrupting a Thread. The action being performed must react to the interruption, and what you are describing suggests that Path.copyTo does not respond to interruption. So Future.cancel will not work.

The next thing I would try would be forcing some other kind of exception to occur. For Path.copyTo it seems an IOException is the most likely. I am not exactly sure how to cause it though. It doesn't look like you have access to the Streams or Channels used for copying the Path, so you can't force close them.

Why do you need to cancel a copyTo operation? It seems unsafe to me.

[Fabiano Santa Clara]

Thank you, Steve.

Steve Luke wrote:(...)Why do you need to cancel a copyTo operation? It seems unsafe to me.

Suppose a user starts to copy a large file and decides to cancel the operation. Do you think it is unsafe?


Thank you

[Mike Simmons]

It seems perfectly reasonable to me to cancel it. It's "unsafe" in that you can't make any assumptions about the content that's been copied; you should probably just delete it.

Unfortunately, it looks like copyTo() simply isn't designed for this. If you need this functionality, you will probably need to write your own copy method, copying small portions at a time, and checking Thread.currentThread().interrupted() periodically. I would use FileChannel's transferTo() or transferFrom() methods to perform the copying, in hopes of getting something more efficient than traditional Java IO copying.

[Fabiano Santa Clara]

Mike Simmons wrote:(...)I would use FileChannel's transferTo() or transferFrom() methods to perform the copying, in hopes of getting something more efficient than traditional Java IO copying.

I've adopted this suggestion. It works perfectly, but I don't know if its performance is better than Path.copyTo.

Thank you all for responses.

[Mike Simmons]

There's no reason to expect it to perform any better than copyTo() - in fact copyTo() probably uses FileChannel under the covers. But both can be considerably better than pre-NIO techniques, reading from an InputStream and writing to an OutputStream. That's what I meant by "traditional Java IO copying".

[Fabiano Santa Clara]

Thank you.

Mike Simmons wrote:There's no reason to expect it to perform any better than copyTo()

So, do you think this is correct way to use transferTo?

FileChannel outChannel = new FileOutputStream(to).getChannel();
FileChannel inChannel = new FileInputStream(file).getChannel();

while (inChannel.size() != outChannel.size() && !isCancelled()) {
	inChannel.transferTo(outChannel.size(), 1024, outChannel);
}

Is '1024' a good checkpoint?

[Mike Simmons]

Sure, sounds good. You can test a bit to see how much effect it has to change the value. If you make the value too large, your system won't respond quickly to a cancellation; if you make it too small, it will be less efficient than a larger read. There's probably a wide range of values that are suitable.

[Spike Fox]

Fabiano Santa Clara wrote:

Mike Simmons wrote:(...)I would use FileChannel's transferTo() or transferFrom() methods to perform the copying, in hopes of getting something more efficient than traditional Java IO copying.

I've adopted this suggestion. It works perfectly, but I don't know if its performance is better than Path.copyTo.

Thank you all for responses.

I have coded a program which is used to test the performance. Finally i find implementing the copy file by FileChannel can take better performance than Path.copyTo.

[Fabiano Santa Clara]

Spike Fox wrote:I have coded a program which is used to test the performance. Finally i find implementing the copy file by FileChannel can take better performance than Path.copyTo.

When the target file is under the same FileStore of source file, I realized that the performance of FileChannel is as fast as cp command.

Thank you all for the posts.