Standardmethode zum Kopieren einer Datei in Java?

Question

Es hat mich schon immer gestört, dass die einzige Möglichkeit, eine Datei in Java zu kopieren, darin besteht, Streams zu öffnen, einen Puffer zu deklarieren, eine Datei einzulesen, sie in einer Schleife zu durchlaufen und sie in die andere Datei zu schreiben. Das Web ist übersät mit ähnlichen, aber dennoch leicht unterschiedlichen Implementierungen dieser Art von Lösung.

Gibt es einen besseren Weg, der innerhalb der Grenzen der Java-Sprache bleibt (d.h. ohne die Ausführung von OS-spezifischen Befehlen)? Vielleicht in einem zuverlässigen Open-Source-Utility-Paket, das zumindest die zugrunde liegende Implementierung verschleiert und eine Ein-Zeilen-Lösung bietet?

Answer 1

Um eine Datei zu kopieren und in Ihrem Zielpfad zu speichern, können Sie die folgende Methode verwenden.

public void copy(File src, File dst) throws IOException {
    InputStream in = new FileInputStream(src);
    try {
        OutputStream out = new FileOutputStream(dst);
        try {
            // Transfer bytes from in to out
            byte[] buf = new byte[1024];
            int len;
            while ((len = in.read(buf)) > 0) {
                out.write(buf, 0, len);
            }
        } finally {
            out.close();
        }
    } finally {
        in.close();
    }
}

Answer 2

Beachten Sie, dass alle diese Mechanismen nur den Inhalt der Datei kopieren, nicht aber die Metadaten wie z. B. die Berechtigungen. Wenn Sie also eine ausführbare .sh-Datei unter Linux kopieren oder verschieben würden, wäre die neue Datei nicht ausführbar.

Um eine Datei wirklich zu kopieren oder zu verschieben, d.h. um das gleiche Ergebnis wie beim Kopieren von der Kommandozeile zu erzielen, müssen Sie ein natives Werkzeug verwenden. Entweder ein Shell-Skript oder JNI.

Anscheinend wird dies in Java 7 behoben - http://today.java.net/pub/a/today/2008/07/03/jsr-203-new-file-apis.html . Daumen drücken!

Answer 3

Die Guava-Bibliothek von Google hat auch eine Kopiermethode :

public static void **copy**([File](http://download.oracle.com/javase/6/docs/api/java/io/File.html?is-external=true "class or interface in java.io") from,
                        [File](http://download.oracle.com/javase/6/docs/api/java/io/File.html?is-external=true "class or interface in java.io") to)
                 throws [IOException](http://download.oracle.com/javase/6/docs/api/java/io/IOException.html?is-external=true "class or interface in java.io")

Kopiert alle Bytes von einer Datei in eine andere.

Warnung: Si to eine bestehende Datei darstellt, wird diese Datei wird mit dem Inhalt von from . Wenn to et from beziehen sich auf die dieselbe Datei, der Inhalt dieser Datei gelöscht werden.

Parameter: from - die Quelldatei to - die Zieldatei

Wirft: [IOException](http://download.oracle.com/javase/6/docs/api/java/io/IOException.html?is-external=true "class or interface in java.io") - wenn ein E/A-Fehler auftritt [IllegalArgumentException](http://download.oracle.com/javase/6/docs/api/java/lang/IllegalArgumentException.html?is-external=true "class or interface in java.lang") - wenn from.equals(to)

Answer 4

Als Standard in Java 7 verfügbar, path.copyTo: http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html http://java.sun.com/docs/books/tutorial/essential/io/copy.html

Ich kann nicht glauben, dass sie so lange gebraucht haben, um etwas so Alltägliches und Einfaches wie das Kopieren von Dateien zu standardisieren :(

Answer 5

Drei mögliche Probleme mit dem obigen Code:

1. Wenn getChannel eine Ausnahme auslöst, kann es sein, dass Sie einen offenen Stream verlieren.
2. Bei großen Dateien versuchen Sie möglicherweise, mehr auf einmal zu übertragen, als das Betriebssystem bewältigen kann.
3. Sie ignorieren den Rückgabewert von transferFrom, so dass möglicherweise nur ein Teil der Datei kopiert wird.

Das ist der Grund org.apache.tools.ant.util.ResourceUtils.copyResource so kompliziert ist. Beachten Sie auch, dass transferFrom zwar OK ist, transferTo aber unter JDK 1.4 unter Linux nicht funktioniert (siehe Fehler-ID:5056395 ) - Jesse Glick Jan