File renameTo Verständigungsproblem

[diesy]

Hallo,

ich bins nochmal!

Ich habe ein kleines Verständigungsproblem bei der Beschreibung der Funktion renameTo() aus File Klasse.

Many aspects of the behavior of this method are inherently platform-dependent: The rename operation might not be able to move a file from one filesystem to another, it might not be atomic, and it might not succeed if a file with the destination abstract pathname already exists. The return value should always be checked to make sure that the rename operation was successful.

Meinen die mit filesystem z.B.: FAT -> NTFS und umgekehrt. Bzw. EXT3 -> EXT2, ... ?

Oder meinen die Jungs von Sun damit die Laufwerke?

Ich habe es probiert und es klappt eigentlich zwischen den Laufwerken.

Gruß diesy.

[perdian]

Meinen die mit filesystem z.B.: FAT -> NTFS und umgekehrt. Bzw. EXT3 -> EXT2 [...] Oder meinen die Jungs von Sun damit die Laufwerke?

Sowohl als auch.

Ich habe es probiert und es klappt eigentlich zwischen den Laufwerken.

Daraus kannst du aber nicht folgern, dass es auf allen Betriebssystemen und allen Filesystemen auch der Fall ist. Genau das sagt der Satz in der Doku.

[Sigi]

platform-dependent :>

[diesy]

@perdi

du kannst folgenden code ja ausprobieren:

import java.io.File;

import java.io.IOException;

import java.util.Date;


public class WriteTest

{    

    public static void main(String[] args) throws IOException

    {

        Date d = new Date();

        System.out.println(d.getTime());


        File f = new File("c:\\datei.jpg");    

        f.renameTo(new File("g:\\copy.jpg"));


        d = new Date();

        System.out.println(d.getTime());        

    }    

}

Du musst jeweils die Dateinamen anpassen und die Laufwerksbuchstaben.

Die Datei muss auch exestieren.

[perdian]

du kannst folgenden code ja ausprobieren:

Warum?

Dann hättest du die Info wie es unter WinXP und NTFS funktioniert, aber immer noch keine Garantie dafür, dass es z.B. unter WinXP und FAT oder Linux und ReiserFS auch so ist. Ganz davon abgesehen habe ich eh nur ein Laufwerk

[diesy]

dann wäre dass das zweite OS wo es funktioniert.

und da linux und fat heute eh nur einen geringen anteil darstellen, wäre das verkraftbar.

gibt es sonst eine lösung, dateien, von einem laufwerk auf einen anderen zu verschieben. ohne sie mit streams dorthin zu schreiben, da diese methode sehr zeitaufwändig ist.

[Pinhead]

und da linux und fat heute eh nur einen geringen anteil darstellen, wäre das verkraftbar.

Und weil kaum jemand einen anderen Browser nutzt als den InternetExplorer muss auch kein valides HTML "programmiert" werden. :beagolisc Also ich kenne wenige ApplicationServer die tatsächlich auf Windows in der Praxis sind. Und warum sollte ich eine plattform unabhänige Sprache benutzen wenn ich sie so verwenden das sie plattform abhängig wird ?

gibt es sonst eine lösung, dateien, von einem laufwerk auf einen anderen zu verschieben.

STRG + X STRG + V;)

ohne sie mit streams dorthin zu schreiben, da diese methode sehr zeitaufwändig ist.

Zeitaufwändig zur Laufzeit oder während der Entwicklung ?

[perdian]

und da linux und fat heute eh nur einen geringen anteil darstellen, wäre das verkraftbar.

Ist das die Art und Weise, wie du Probleme "löst", die sich irgendwann stellen? Selbst wenn wir mal davon ausgehen, dass du damit im Moment gut fährst - wer garantiert dir denn, dass unter Windows Vista das Verhalten auch noch in Ordnung ist? Was passiert wenn dein Kunde nächstes Jahr beschließt zu wechseln? Wer garantiert dir, dass das Verhalten unter Mustang auch noch so ist, wie du es jetzt gewohnt bist? Auf solche "ausprobiert, klappt im Moment auch" Lösungen würde ich immer verzichten wollen.

gibt es sonst eine lösung, dateien, von einem laufwerk auf einen anderen zu verschieben. ohne sie mit streams dorthin zu schreiben, da diese methode sehr zeitaufwändig ist.

Hast du das tatsächlich ausgetestet, (mit einem Profiler) gemessen und damit diese Aussage verifizieren können? Oder glaubst du nur, dass es - merklich - länger dauert? Vorzeitig anzunehmen, dass in diesem Falle ein Copy länger dauert als ein rename verleitet sehr schnell zu falschen Annahmen. Was ist, wenn renameTo (je nach Plattform) intern genau das macht?

Und selbst wenn es 10x so lange dauert eine Datei zu kopieren, als sie umzubenennen - bist du wirklich sicher, dass genau diese Aktion der Bottleneck deiner Anwendung ist? Hast du tausende Files, die es zu verschieben gilt?

[diesy]

Und weil kaum jemand einen anderen Browser nutzt als den InternetExplorer muss auch kein valides HTML "programmiert" werden. Also ich kenne wenige ApplicationServer die tatsächlich auf Windows in der Praxis sind. Und warum sollte ich eine plattform unabhänige Sprache benutzen wenn ich sie so verwenden das sie plattform abhängig wird ?

ja, wenn man webserver und co nimmt, dann hat windows sicherlich einen kleinen nachteil. aber wenn es um den dau geht, dann fahren die meisten mit xp und auch ohne firewall + av rum!

STRG + X STRG + V

muss automatisch geschehen, nicht manuell deswegen ist renameTo() schon nicht schlecht.

Zeitaufwändig zur Laufzeit oder während der Entwicklung ?

Zeitaufwändig zur Laufzeit!

Um eine 1,6 MB große Datei 10 mal auf einen anderen laufwerk zu schreiben braucht man sehr lange! habe das mit den zeiten getestet, war nicht akzeptabel.

[diesy]

Ist das die Art und Weise, wie du Probleme "löst", die sich irgendwann stellen? Selbst wenn wir mal davon ausgehen, dass du damit im Moment gut fährst - wer garantiert dir denn, dass unter Windows Vista das Verhalten auch noch in Ordnung ist? Was passiert wenn dein Kunde nächstes Jahr beschließt zu wechseln? Wer garantiert dir, dass das Verhalten unter Mustang auch noch so ist, wie du es jetzt gewohnt bist? Auf solche "ausprobiert, klappt im Moment auch" Lösungen würde ich immer verzichten wollen.

Ich habe ja noch nicht behauptet dass mir diese Lösung gefällt! Da sie halt eben nicht perfekt ist! Und ich auch die "Plattformunabhängigkeit" garantieren will.

Hast du das tatsächlich ausgetestet, (mit einem Profiler) gemessen und damit diese Aussage verifizieren können? Oder glaubst du nur, dass es - merklich - länger dauert? Vorzeitig anzunehmen, dass in diesem Falle ein Copy länger dauert als ein rename verleitet sehr schnell zu falschen Annahmen. Was ist, wenn renameTo (je nach Plattform) intern genau das macht?

Und selbst wenn es 10x so lange dauert eine Datei zu kopieren, als sie umzubenennen - bist du wirklich sicher, dass genau diese Aktion der Bottleneck deiner Anwendung ist? Hast du tausende Files, die es zu verschieben gilt?

ich habe das zwar nicht mit einem Profiler getestet aber ein einfaches Date() reicht aus um zu sagen, dass es sehr lahm ist. Da geht der einfache Windows-Copy schneller!

ich kann dir gerne 2 Varianten anfertigen, einmal mit renameTo() und einmal mit dem Input/OutputStreamWriter.

Darfst es selber testen, indem du paar MB große Dateien mal selbst auf einem Laufwerk verschiebst.

[perdian]

Um eine 1,6 MB große Datei 10 mal auf einen anderen laufwerk zu schreiben braucht man sehr lange!

Sehr lange ist immer ein relativer Zeitraum. Da kommen in der Regel noch ganz andere Bewertungskriterien mit ins Spiel. Wie oft muss die Operation durchgeführt werden, wie lange dauert ein Lauf, etc.

Was du dir vielleicht bewusst machen solltest: Wenn ich Datei X von Laufwerk A auf Laufwerk B spiele und Laufwerk B physikalisch auf einer anderen Festplatte liegt als Laufwerk A, dann wirst du immer die Datei komplett kopieren müssen, da hilft dir auch kein rename weiter. Ungetestet glaube ich sogar, dass Windows generell zwischen zwei Laufwerken immer kopiert und löscht und nicht wirklich nur verschiebt.

Es gibt also - je nach Situation - gar keine andere Möglichkeit.

habe das mit den zeiten getestet, war nicht akzeptabel.

Hast du auch getestet ob wirklich der Datentransfer (also das Schaufeln der einzelnen Bytes) so lange gedauert hat, oder ob nicht andere bremsende Faktoren im Spiel waren? Richtiges Benchmarking und das Suchen von Performance-Schwachstellen ist eine Kunst für sich.

Wie verläuft dein Kopieren an sich? Direkt oder gepuffert? Alleine zwischen diesen Zwei alternativen Übertragungsmöglichkeiten liegen schon teilweise Welten was das Laufzeitverhalten angeht.

Darfst es selber testen, indem du paar MB große Dateien mal selbst auf einem Laufwerk verschiebst.

Glaubst du ich habe noch nie mit Java Dateien verschoben? Ich habe einige Backups Jobs laufen, da sind deine paar MB nix gegen. Und wirkliche Performance-Probleme habe ich damit noch nie gehabt. IO-Operationen sind immer mehr oder weniger zeitaufwändig. Da lässt sich auch nichts dran ändern - siehe die Erläuterung weiter oben.

ich habe das zwar nicht mit einem Profiler getestet aber ein einfaches Date() reicht aus um zu sagen, dass es sehr lahm ist.

Was hat das erstellen eines Date Objektes (so interpretiere ich "ein einfaches Date()" jetzt einfach mal) mit der Geschwindigkeit von IO Prozessen zu tun?

[diesy]

ok, habe jetzt den test gemacht:

Datei: 4.380.275 Byte

StreamWriter: 11,33 sek

renameTo(): 0,0086 sek

1146087124687 - zeit 1

1146087165484 - zeit 2 - nach dem schreiben mit dem FileOutputStream

1146087165515 - zeit 3 - nach dem kopieren mit renameTo() Funktion

Date hat damit zu tun, dass ich damit die zeit am einfachsten messe.

der code dafür sieht so aus:

public static void copyBytes(String iFile, String oFile) throws IOException

{

File inputFile = new File(iFile);

File outputFile = new File(oFile);

FileInputStream in = new FileInputStream(inputFile);

FileOutputStream out = new FileOutputStream(outputFile);

int c;

while ((c = in.read()) != -1)

out.write©;

in.close();

out.close();

//inputFile.delete();

}

public static void main(String[] args) throws IOException

{

Date d = new Date();

System.out.println(d.getTime());

copyBytes("c:\\test\\testdatei.jpg", "c:\\test\\copy_stream\\copy.jpg");

d = new Date();

System.out.println(d.getTime());

File f = new File("c:\\test\\testdatei.jpg");

f.renameTo(new File("c:\\test\\copy_rename\\copy.jpg"));

d = new Date();

System.out.println(d.getTime());

}

wenn du es besser weisst, kannst mir ja einen lösungsvorschlag mal machen oder eine lösung verraten, ich bin für alles offen! Und ich brauche keine Gigabyte zu verschieben, es reicht wenn das nur paar MB sind.

[Schiller256]

Also das dein copy so lange braucht liegt daran das er ungepuffert gemacht wird. Wenn di da einen Puffer dazwischen stellst dann geht das ganze schon gleich viel schneller. Deine copyBytes Methode musst du mal noch um ein paar Zeilen erweitern.

… 

byte[] buffer = new byte[1000];

// die while schleife mal etwas abändern

while ((c = in.read(buffer)) != -1) {

    out.write(buffer, 0, c);

}

…

// jetzt kannst du die alte Datei löschen

Ich habe das jetzt mal auf einem Windows XP schnell getestet einen Unterschied zur ungepufferten Methode merkt mal deutlich. Einen Unterschied zwischen der gepufferten und der renameTo Methode kann ich jetzt nicht feststellen. Nur eben das die Datei nach dem umbenennen nicht mehr am Ausgangsort zu finden ist.

[diesy]

danke schiller! deine lösung hilft mir weiter!

es ist wirklich ein unterschied wie tag und nacht!

[perdian]

danke schiller! deine lösung hilft mir weiter!

Genau dafür gibt's auch BufferedInputStream und BufferedOutputStream.

es ist wirklich ein unterschied wie tag und nacht!

Soviel zu "im Vorfeld intensiv durchgetestest"