This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes How do I stop Path.copyTo (nio2 method)? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "How do I stop Path.copyTo (nio2 method)?" Watch "How do I stop Path.copyTo (nio2 method)?" New topic
Author

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

Fabiano Santa Clara
Greenhorn

Joined: Sep 20, 2009
Posts: 6
I've tried just wrap the transfer in a FutureTask and pass it to an Executor, but the transfer doesn't stop.
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 787

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.


SCJP 5.0 - JavaRanch FAQ - Java Beginners FAQ - SCJP FAQ - SCJP Mock Tests - Tutorial - JavaSE7 - JavaEE6 -Generics FAQ - JLS - JVM Spec - Java FAQs - Smart Questions
Fabiano Santa Clara
Greenhorn

Joined: Sep 20, 2009
Posts: 6
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: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
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

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.


Steve
Fabiano Santa Clara
Greenhorn

Joined: Sep 20, 2009
Posts: 6
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
Ranch Hand

Joined: Mar 05, 2008
Posts: 3012
    
  10
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
Greenhorn

Joined: Sep 20, 2009
Posts: 6
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
Ranch Hand

Joined: Mar 05, 2008
Posts: 3012
    
  10
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
Greenhorn

Joined: Sep 20, 2009
Posts: 6
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?Is '1024' a good checkpoint?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3012
    
  10
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
Greenhorn

Joined: Sep 21, 2009
Posts: 8
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
Greenhorn

Joined: Sep 20, 2009
Posts: 6
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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: How do I stop Path.copyTo (nio2 method)?