Ich habe folgendes Problem in Java. Eigentlich will ich nur ganz simpel eine Datei umbenennen, aber mit
s = "C:\\Programme\\eclipse\\workspace\\Testarea\\NocheinTestRename\\MyTest.txt";
file.renameTo(new File(s));
klappt das leider nicht. dieses renameTo() gibt mir ein false zurück, welches mir mitteilt, dass das Umbenennen nicht geklappt hat, leider aber nicht den Grund dafür. Die umzubenennende Datei ist nicht schreibgeschützt.
Hat jemand ne Ahnung, woran das liegen kann?
besteht das problem unter Windows? wenn ja, ist es wohl ein bekanntes Problem. googeln hilft [img]
http://www.fb18.de/gfx/22.gif[/img]
zum beispiel hier
Und wie mache ich das dann, ohne eine Datei einzulesen, zu löschen und dann eine neue zu schreiben?
vielleicht musst Du vor dem renameTo den BufferdStream (oder was auch immer file sein soll) schliessen.
ein file.close(); vor dem renameTo wäre ein Versuch wert.
Ich habe folgendes Problem in Java. Eigentlich will ich nur ganz simpel eine Datei umbenennen, aber mit
s = "C:\\Programme\\eclipse\\workspace\\Testarea\\NocheinTestRename\\MyTest.txt";
file.renameTo(new File(s));
Hat jemand ne Ahnung, woran das liegen kann?
bin grad nicht zu Hause zum testen/ Beispiele posten,
aber bisschen strukturierter sollte doch gehen,
File fAlt = ..
File fNeu = fAlt.getAbsoluthpath()+ File.seperator+newName;
if (fNeu.exists()) {
if (!fneu.delete()) {
// Fehler, Verzeichnis?, Zugriff?
}
}
if (!fAlt.renameTo(fNeu)) {
// Fehler
};
auch schon mal getestet ob es nicht eher "C:/Programme/eclipse/.." ist?
bzw. ob überhaupt das Verzeichnis existiert? (Tippfehler, Gross- Kleinschreibung)
liegt die alte Datei im gleichen Verzeichnis,
funktioniert es im C:\\ Hauptverzeichnis,
findet Java überhaupt Dateien (exists())
file ist ein File, eine Datei halt. Und das Verzeichnis existiert, so auch die Datei. Der Pfad müsste auch stimmen, denn sonst könnte ich ihn mir nicht ausgeben lassen
(Das Programm bisher nimmt den Pfad, geht in das Verzeichnis, liest alle Files in ein File[] ein, gibt diese einmal per System.out.println() aus, und soll sie dann umbenennen, und nur letzteres will nicht).
file ist ein File, eine Datei halt. Und das Verzeichnis existiert, so auch die Datei. Der Pfad müsste auch stimmen, denn sonst könnte ich ihn mir nicht ausgeben lassen
(Das Programm bisher nimmt den Pfad, geht in das Verzeichnis, liest alle Files in ein File[] ein, gibt diese einmal per System.out.println() aus, und soll sie dann umbenennen, und nur letzteres will nicht).
Wenn das Programm ohnehin schon in das Verzeichnis gewechselt ist, könntest Du das doch bei der neuen Datei ohne Pfadangabe probieren.
Funktioniert leider auch nicht.
..das muss doch möglich sein, einfach nur eine Datei umzubenennen [img]
http://www.fb18.de/gfx/19.gif[/img]
Hast Du, wie von Crisp vorgeschlagen, die Dateien zuerst geschlossen? Gerade ein wohlbekanntes Dateisystem unter einer wohlbekannten Plattform mag es ja gar nicht, wenn man Dinge mit geöffneten Dateien anstellt.
BTW: Welches Windows mit meldem Dateisystem ist es denn bei Dir?
Ich hab die Datei doch nichtmal geöffnet..(?) Naja, kann es ja mal testen..
EDIT: Geht natürlich nicht, weil File gar keine Funktion wie close() hat..
Ich hab Win XP Pro mit NTFS
Geht natürlich nicht, weil File gar keine Funktion wie close() hat..
Ach ja, in Java ist die Klasse "File" ja nicht für den Zugriff auf die Dateien. Ich dachte, man würde die Datei vielleicht implizit beim erstellen des Objekts öffnen. Falsch gedacht.
Du versuchst auch nicht, von einem/einer Dateisystem/Laufwerk/Partition in ein anderes zu verschieben?
Ne, die ist im selben Verzeichnis, die soll nur umbenannt werden.
Geht natürlich nicht, weil File gar keine Funktion wie close() hat..
[img]
http://www.fb18.de/gfx/15.gif[/img] war aber ein Versuch wert. Fragt sich nur, woher ich File.close() kenne???
crisp schrieb:Geht natürlich nicht, weil File gar keine Funktion wie close() hat..
[img]http://www.fb18.de/gfx/15.gif[/img] war aber ein Versuch wert. Fragt sich nur, woher ich File.close() kenne???
Liegt ja nicht so fern und in vielen Bibliotheken (v.a. andere Sprachen) gibt es das ja auch.
Zaphod schrieb:Ne, die ist im selben Verzeichnis, die soll nur umbenannt werden.
Hmmm, langsam gehen mir die Ideen aus. Zu dumm, das man Java da nach keine Fehlermeldung fragen kann.
In der Eingabeaufforderung funktioniert "REN alterPfad neuePfad" aber, oder?
Nur um das nocheinmal zu rekapitulieren: Die Quelldatei "file" hattest Du nicht erst in dem Programm erzeugt oder etwas in sie geschrieben?
Was gibt es denn für Rückgabewerte, wenn Du an der Quelldatei .canRead() und .canWrite() abfragst? Und kannst Du die Datei mit .delete() löschen?
Muss ich testen, wenn sich meine Müdigkeit gelegt hat [img]
http://www.fb18.de/gfx/25.gif[/img]
file existiert schon vorher, m ein programm macht damit nichts, außer den Versuch, sie umzubenennen.
Also bei mir ist das Umbenennen kein Problem:
public class Test1 {
public static void main(String[] args) {
File fAlt = new File("C:\\eclipse-SDK-2.1.1-win32\\eclipse\\workspace\\Test001\\alt.txt");
File fNeu = new File("C:\\eclipse-SDK-2.1.1-win32\\eclipse\\workspace\\Test001\\neu.txt");
System.out.println(fAlt.renameTo(fNeu));
}
}
Ausgabe: true
und die Datei wurde von alt.txt zu neu.txt umbenannt.
Hmm… komisch. Ich hab nichts geändert, aber eben hat es funktioniert…
–> nichtlinearer Strukturunwille [img]
http://www.fb18.de/gfx/22.gif[/img]
Du wolltest keine .mp3 umbenennen, die Du zu dem Zeitpunkt gehoert hast, oder?
Das funktioniert nur unter Unix :D
MoKrates
Du wolltest keine .mp3 umbenennen, die Du zu dem Zeitpunkt gehoert hast, oder?
Winblows stellt sich ja wirklich immer sehr an, wenn es daran geht, etwas mit einer Datei zu machen, die geöffnet ist. Und ich habe oft auch schon erlebt, daß es Probleme gibt, wenn eine Programm eine Datei eben noch geöffnet hatte, jetzt aber sie schon geschlossen haben sollte. Sogar das beenden des Programms reicht dann z.T. nicht. [img]
http://www.fb18.de/gfx/26.gif[/img]
Keine Ahnung ob das an schlechter Programmierung oder dem OS liegt, aber "Ich muß neu booten, damit mir Windows vielleicht erlaubt, diese Datei zu löschen (nicht nur in den Papierkorb werfen)" klingt wie ein schlechter Witz. Und ich hatte den Eindruck, daß dies mit der Windowsevolution nur z.T. behoben wurde.
[img]
http://www.fb18.de/gfx/1.gif[/img] Nein, dies ist kein Windows-Rant, sondern nur eine Erlebnisbeschreibung.
Sogar das beenden des Programms reicht dann z.T. nicht. [img]http://www.fb18.de/gfx/26.gif[/img]
Das liegt wahrscheinlich daran, dass manche Programmierer die nette Eigenschaft eigentlich jeden OS'es nutzen, dass man Dateien beim beenden eines Prozesses *eigentlich* nicht schliessen muss, da das OS das tun sollte.
Dass Windows allerdings nicht so toll beim Aufraeumen des Drecks ist, den Prozesse hinterlassen, wenn sie beendet werden, ist, zumindest mir, schon laenger bekannt.
MoKrates
Edit: Aehnliche Probleme gibts allerdings auch (selten) mit Linux. Listen-Ports scheinen auch mit Zeitverzoegerung geschlossen zu werden.
Das liegt wahrscheinlich daran, dass manche Programmierer die nette Eigenschaft eigentlich jeden OS'es nutzen, dass man Dateien beim beenden eines Prozesses *eigentlich* nicht schliessen muss, da das OS das tun sollte.
Sich darauf zu verlassen halte ich aber für keinen sehr guten Programmierstil. Offensichtlich stößt er auch schon bei der Portabilität an seine Grenzen. Dumm auch, wenn das Programm dann doch langlebiger ist als vom Programmierer zuerst gedacht und dadurch zum Resourcenloch wird.
BTW: Wenn mir die Laufzeitumgebung meiner Sprache garantiert, daß Dateien geschlossen werden, nachdem die Referenzen darauf fallen gelassen wurden, nutze ich das durchaus gerne. Allerdings muß man sich auch dort bewußt sein, daß dies in der Regel nicht sofort passiert.
Sich darauf zu verlassen halte ich aber für keinen sehr guten Programmierstil.
ist es auch nicht. Aber vor allem bei graphischen Programmen gibt es teilweise eine solche Unzahl von Moeglichkeiten ein Programm zu beenden oder auch zu toeten, dass auch ein Programmierer sich nicht darauf verlassen kann, dass sein Code tatsaechlich ausgefuehrt wird.
Offensichtlich stößt er auch schon bei der Portabilität an seine Grenzen. Dumm auch, wenn das Programm dann doch langlebiger ist als vom Programmierer zuerst gedacht und dadurch zum Resourcenloch wird.
Nein, partabel ist das. Unix und Windows tun das beide, gut, wie das bei anderen Systemen aussieht, weiss ich nicht, wird aber aehnlich sein, weil sonst sehr schnell die Systemstabilitaet gefaehrdet ist.
BTW: Wenn mir die Laufzeitumgebung meiner Sprache garantiert, daß Dateien geschlossen werden, nachdem die Referenzen darauf fallen gelassen wurden, nutze ich das durchaus gerne.
Allerdings muß man sich auch dort bewußt sein, daß dies in der Regel nicht sofort passiert.
Normalerweise macht das, wie gesagt, das OS und nicht die Runtime-Umgebung (gut, bei Binaries ist das OS die Umgebung), aber das mit dem Referenzen fallen lassen laesst sich ja nur auf Garbage Collection anwenden, die normalerweise von OS'en nicht betrieben wird.
MoKrates
