How do I copy a file?

[Corey McGlone]

I'm working on a project in which I need to copy various files. Basically, I have some copies in one location and I need to place copies of those files elsewhere but it's imperative that the original file remain in its place.
Using the java.io.File class, I have found that I can use renameTo in order to move a file from one location to another. This works great if I really wanted to MOVE the file, but I want the original to stay where it is and make a copy. Unfortunately, the only way that I have found to do this is to create a FileInputStream and a FileOutputStream and copy the contents of the file from source to destination byte by byte. Needless to say, this is inefficient - not to mention that, if I need to copy files over a network (which may very well occur), it's unbearably slow.
So does anyone know of a good way to copy a file?
Thanks,
Corey

[John Ipe]

would it be an option for you to use Runtime.exec(). you could specify your OS's copy command in the parameter? and if the destination directory is a network drive that's mapped locally, it should still work?
hope i understood you right!
regards

[chi Lin]

For efficiency, you can use java.nio package for copy.
e172 of Java almanac 1.4

// e172 copy one file to another 
    try {
        // Create channel on the source
        FileChannel srcChannel = new FileInputStream("srcFilename").getChannel();
    
        // Create channel on the destination
        FileChannel dstChannel = new FileOutputStream("dstFilename").getChannel();
    
        // Copy file contents from source to destination
        dstChannel.transferFrom(srcChannel, 0, srcChannel.size());
    
        // Close the channels
        srcChannel.close();
        dstChannel.close();
    } catch (IOException e) {
    }

[Corey McGlone]

Originally posted by John Ipe:
would it be an option for you to use Runtime.exec(). you could specify your OS's copy command in the parameter

I believe that is a possibility, but how do I find out what the copy command is so that I can pass that as the parameter? I looked into the API Spec and I'm afraid that I found very little.

[John Ipe]

Originally posted by chi Lin:
For efficiency, you can use java.nio package for copy.
e172 of Java almanac 1.4
[/CODE]

very neat! Corey, I guess you'd want to go with this then?

[Chris Harris]

Hi

The Runtime.exec() is used to execute external programs. So there is no reason why you could not use it to call the copy command on your OS. But I would NOT recommend you do is. You code will soon end up messy as the parameters changed for different OS. First the copy program is different for windows and unix i.e "copy" and "cp". Also different windows platforms need different shells i.e. NT = cmd and 98 = command. If you do this you are losing one of the advantages of writing code that is platform independent.
I therefore recommend that you use channels to read and write the file in a new location. However if you have to write code that runs in 1.3 (This is something that I am forced to do at work) have a look are the old io package for an appropriate reader and a writer.
Chris.

[Lasse Koskela]

If you're sticking with the FileInputStream/FileOutputStream solution (I probably would), you should at least use a buffer instead of reading and writing byte-by-byte.

[Corey McGlone]

Originally posted by chi Lin:
For efficiency, you can use java.nio package for copy.
e172 of Java almanac 1.4

I have to admit, I was amazed at just how well this works. I imagined this would still be too slow, but I am now able to move a hundred megs of data (or more) over our network in a matter of seconds using this technique. It is most definitely fast enough for what my application requires.
And, in addition, it doesn't connect to the underlying OS directly, so I don't lose my portability.
Thanks a ton.

[marlon tan]

Originally posted by chi Lin:
For efficiency, you can use java.nio package for copy.
e172 of Java almanac 1.4

// e172 copy one file to another 
    try {
        // Create channel on the source
        FileChannel srcChannel = new FileInputStream("srcFilename").getChannel();
    
        // Create channel on the destination
        FileChannel dstChannel = new FileOutputStream("dstFilename").getChannel();
    
        // Copy file contents from source to destination
        dstChannel.transferFrom(srcChannel, 0, srcChannel.size());
    
        // Close the channels
        srcChannel.close();
        dstChannel.close();
    } catch (IOException e) {
    }

Hi,
I have a question regarding this method of copying file. dstFilename is very frequently read by another Java program. Is it possible that while executing dstChannel.transferFrom() method (while FileChannel is in the process of copying bytes of data), the other java program (simultaneously) reads dstFilename, will dstFilename be blank, or will the java program read half of what is supposed to be written to dstFilename?
Thank you very much
Regards,
Marlon

[Max Habibi]

You could get a FileLock from the fileChannel, and that's intra-process. However, it's not always to be counted on. Some people create their own monitors. That is, your method might create a ".lock" file in the directory, then delete it when exiting.
Of course, if you found a ".lock" file, you'd be obligated to wait.
All best,
M

[Thomas Paul]

The knuckleheads at Sun have been ignoring this problem since Java came out. Here is a bug that was submitted in 1997:
http://developer.java.sun.com/developer/bugParade/bugs/4032604.html
Makes me wonder what they are smoking at Sun if they think copying a file has different meanings (not implementations) on a Sun server as opposed to a Macintosh.
In my opinion, the developers at Sun are way too concerned about making simple things complicated (see the JSF specification) and not concerned enough about fixing serious holes in J2SE.

[Manish Hatwalne]

Just curious, what makes NIO channels significantly faster than older IOStreams or reader/writers?
- Manish

[Ben Poole]

Add me to the list of those curious about this! If I get time I'll investigate... I assume it's essentially down to some buffering.

[Jim Yingst]

Just curious, what makes NIO channels significantly faster than older IOStreams or reader/writers?
They rely more heavily on native code, which often in turn can rely on your platform's hardware optimizations. The OS can tell the hard drive to copy from one spot on the disk to another; this may be accomplished without actually sending the data across the bus to the CPU or anywhere else. Traditional Java IO on the other hand requires that each and every byte of data be copied from the hard drive into a byte or byte[] in the JVM heap, and from there, copied back to the hard drive.
What I've described above for NIO is a best-case scenario, using the transferTo() or transferFrom() methods. Other NIO techniques rely on ByteBuffers instead, which will be a little slower than transferTo() because the bytes typically have to be transferred to RAM somewhere - but this is often still faster than IO classes because the RAM used by ByteBuffers is managed by the OS, not by the JVM, and so it's (probably) better optimized using native code for that platform.
The above statements are mostly from memory, and may well be mistaken in some aspects, so corrections welcome. A good resource is Java NIO from O'Reilly.
[ March 05, 2004: Message edited by: Jim Yingst ]

[Ron Perrella]

Originally posted by Thomas Paul:
The knuckleheads at Sun have been ignoring this problem since Java came out. Here is a bug that was submitted in 1997:

http://developer.java.sun.com/developer/bugParade/bugs/4032604.html

Makes me wonder what they are smoking at Sun if they think copying a file has different meanings (not implementations) on a Sun server as opposed to a Macintosh.

In my opinion, the developers at Sun are way too concerned about making simple things complicated (see the JSF specification) and not concerned enough about fixing serious holes in J2SE.

Oddly enough, I was one of the original complainers at the time. Clearly, sun is trying to develop multiplatform software while knowing only UNIX. UNIX has a very simple definition of files. Other platforms (indeed ALL OTHER platforms) have more sophisticated files. Resource Folks on Mac, Windows has additional streams of some kind, BeOS, MVS, VM/CMS, VAX/VMS,you name it. Even UNIX for God's stake! Hey Sun, ever heard of ACL? (hint: its in Solaris)?

Of course, they still haven't fixed it.

[Stefan Wagner]

Originally posted by Ron Perrella:

UNIX has a very simple definition of files. Other platforms (indeed ALL OTHER platforms) have more sophisticated files. Resource Folks on Mac, Windows has additional streams of some kind, BeOS, MVS, VM/CMS, VAX/VMS,you name it.

Ron can you give some additional hints on sophisticated files?
I didn't mention any when I used windows last times, perhaps I'm missing something.

Linux has the sophisticated symbolic link(, and the somehow suspicious /dev /proc /sys filesystems).
Isn't a stream a very different thing than an file? Related, of course, deals with files, okay.

[Renee Doran]

In the code snippet given in this topic the close of the channels happens in the try block. Should this be moved to a finally?

[Fletcher Estes]

Originally posted by Renee Doran:
In the code snippet given in this topic the close of the channels happens in the try block. Should this be moved to a finally?

Give the guy a break! And what if the close methods throw an IOException? What then?!

[Aurelien Faillon]

I give you some code that work very well...

sorry but the comments are in french...

     public static void copy(File f, String dir, JFrame fra) throws IOException {
    String source_name = f.getName();
        File source_file = f;
 
        String dest_name = dir + sl + source_name;
        File destination_file = new File(dest_name); 
        FileInputStream source = null; 
        FileOutputStream destination = null; 
        byte[] buffer; 
        int bytes_read; 
 
        try { 
        // est-ce que le fichier existe?
        // peut-on le lire?
         if (!source_file.exists()){
         throw new CopyFileException("La source ''" + source_name + "'' n'existe pas");
         }
         if (!source_file.isFile()){
            throw new CopyFileException("La source ''" + source_name + "'' n'est pas un fichier");
         }
         if (!source_file.canRead()){
             throw new CopyFileException("La source ''" + source_name + "'' est bloquee en ecriture");
         }
 
    // si la destination existe, s'assurer qu'on peut l'�craser et
    // s'assurer que l'on peut �crire dans le repertoire de destinantion
             if (destination_file.exists()) { 
                  if (destination_file.isFile()) {           
                       if (!destination_file.canWrite()) {
                             throw new CopyFileException("Impossible d'�crire dans le dossier " + dest_name); 
                       }
              } 
              else {
                    throw new CopyFileException("La destination " +  dest_name + " n est pas un dossier");
                    } 
         } 
         else { 
              File parentdir = parent(destination_file); 
              if (!parentdir.exists()){
                    throw new CopyFileException("La direction '" + dir + "' n'existe pas"); 
              }
              if (!parentdir.canWrite()) {
                    throw new CopyFileException("La direction '" + dir + "' est bloquee en ecriture"); 
              }
         } 
                                                  
            // tout a �t� v�rifi�: lancement de la copie
            source = new FileInputStream(source_file); 
            destination = new FileOutputStream(destination_file); 
            buffer = new byte[1024]; 
            while(true) { 
                bytes_read = source.read(buffer); 
                if (bytes_read == -1)
                break; 
                destination.write(buffer, 0, bytes_read); 
         } 
        } 
    // tout fermer
    finally {
         if (source != null) 
              try { source.close(); } catch (IOException e) { } 
         if (destination != null) 
              try { destination.close(); } catch (IOException e) { } 
    }
 }
                                          
     // traitement du cas ou File.getParent() retourne "null" 
 private static File parent(File f) { 
    String dirname = f.getParent(); 
    if (dirname == null) { 
       if (f.isAbsolute())
       return new File(File.separator); 
       else
       return new File(System.getProperty("user.dir")); 
   } 
   return new File(dirname); 
 } 

and you need so:

 public class CopyFileException extends IOException { 
 public CopyFileException(String msg) {
   super(msg);
 } 
} 

enjoy...