files umbenennen

[newton]

Hi,

ich möche files umbenennen, genauergesagt, ich will dem Filenamen einen präfix voran stellen.
In der Klasse File giebt es die Methode renameTo(File dest).
Mir ist dabei die Syntax nicht ganz klar. Wenn ich es richtig verstehe, erwartet renameTo() ein Objekt vom Typ File. Muss ich dann erst ein neues File mit dem gewünschten Filenamen erzeugen?
Erscheint mir recht umständlich. Giebt es nicht so ein analogon zum Shellkommando 'mv' ?
Würde mich freuen über ein kleines Codebeispiel.

Gruss :)
newton

[Sym]

Das musst Du wohl so machen. Ein neues File erzeugen und dann der Methode übergeben.

[newton]

hm, wenn ich mit createNewFile() ein neues File erzeuge, wie geb ich dem dann nen namen?
:confused:

newton

[peschmae]

wieso nicht einfach ein

File f; // altes file
f.renameTo(new File(f.getParentFile(), "neuaname"));

Sollte doch gehen. So oder ähnlich.

MfG Peschmä

[newton]

Hi
@peschmae
so gehts tatsächlich, vielen Dank! :)

@Lars
hast recht, s.o.
aber mir ist noch nicht ganz klar wiso.

Auf jedenfall erscheint mir das etwas umständlich. Naja, jetzt weis ich ja wies geht ;)

Gruss,
newton

[anda_skoa]

Die Java File Klasse ist ja nicht notwendigerweise einer konkreten Datei im Filesystem zugeordnet, sondern repräsentiert alle nötigen Eigenschaften eine Datei.

Ein solches Objekt beim renameTo zu erwarten ist einfach logisch, das renameTo braucht dann nicht zu raten, hat sicher alle nötigen Informationen und das in einer möglichst plattformunabhängigen Form.

Ciao,
_

[newton]

Die Java File Klasse ist ja nicht notwendigerweise einer konkreten Datei im Filesystem zugeordnet
im Allgemeinen nicht. Aber in dem speziellen Fall, das ich ein File umbenenen will, repraesentiert ja das File Object eine konkrete Datei im Filesystem. Zumindest versteh ich das so. Und damit sollten dann ja auch plattformunabhängig alle nötigen Informationen vorhanden sein.
Das einzige was fehlt ist der neue Dateiname.
Also wiso nicht
file.renameTo(newName) ?

(ja, ich weis, java definert das anders, aber ich versteh leider immer noch nicht wiso :confused: )

Gruss,
newton

[peschmae]

Das hat schon was, das wäre auch eine Möglichkeit - zumindest als überladene Funktion. Eventuell kannst du damit auch verschieben? (Nur eine Vermutung)

MfG Peschmä

[anda_skoa]

im Allgemeinen nicht. Aber in dem speziellen Fall, das ich ein File umbenenen will, repraesentiert ja das File Object eine konkrete Datei im Filesystem. Zumindest versteh ich das so.

Schon richtig.


Also wiso nicht
file.renameTo(newName) ?

Der String müßte in jedem Fall intern wieder in eine File Object umgewandelt werden, um den String so zu parsen, wie das der FIle Konstruktor eben macht.

Der Aufwand renameTo selbst so zu benutzen (also einfach eine temporäre File Instanz zu benutzen) ist minimal, eine zusätzliche Methode die praktisch reduntante Funktionaliät bereitstellt ist üblicherweise nur Ballast in der API (die soll ja so minimal wie möglich sein, solange sie vollständig ist)

Ciao,
_

[newton]

Der Aufwand renameTo selbst so zu benutzen (also einfach eine temporäre File Instanz zu benutzen) ist minimal,
stimmt schon, aber es hat mich als newbie doch sehr verwirrt.


eine zusätzliche Methode die praktisch reduntante Funktionaliät bereitstellt ist üblicherweise nur Ballast in der API (die soll ja so minimal wie möglich sein, solange sie vollständig ist)
auch da muss ich Dir zustimmen. Aber nachdem der einzige Sinn und Zweck der funktion renameTo() ist, einem File nen neuen Namen zu geben, hätte man einfach diese eine Funktion mit einem String als Argument gestalten könnten. Ich sähe da keinen Bedarf für eine zusätzliche Funktion. Mir ist nicht klar, wiso man ein File Object verwenden wollte, bzw. wozu das gut ist.

Der String müßte in jedem Fall intern wieder in eine File Object umgewandelt werden, um den String so zu parsen, wie das der FIle Konstruktor eben macht.
Das hiesse also, um ein File umzubenennen, muss ein neues File erzeugt werden welches alle Eigenschaften vom alten File übernimmt mit Ausnahme des Filenames.

Dann ist mir immer noch nicht klar, wiso renameTo() nicht einfach nur die Info erwartet, die tatsächlich noch fehlt.
Nachdem Java im Allgemeinen ja sehr gut durchdacht ist (soweit ich das beurteilen kann) wuerde ich erwarten, das sich da ein tieferer Sinn hinter verbirgt. :)

Gruss,
newton

[anda_skoa]

stimmt schon, aber es hat mich als newbie doch sehr verwirrt.

Die Java Class Lib API ist an vielen Stellen nicht gerade Newbie freundlich, speziell überall dort, wo große Abstraktion eingesetzt wurde.



Aber nachdem der einzige Sinn und Zweck der funktion renameTo() ist, einem File nen neuen Namen zu geben, hätte man einfach diese eine Funktion mit einem String als Argument gestalten könnten.

Entweder man müßte das dann über Exceptions so einschränken, das nur reine Namen ohne Pfade angegeben werden können, oder man hat intern auch nur die Möglichkeit, eine neue File Instanz zu erzeugen, die das zerlegen in Pfad und Name macht, etc.

Eine Einschränkung auf Umbenennung im selben Verzeichnis ist normalerweise nicht akzeptabel, weil das bei keiner anderen Sprache bzw Basisbibliothek üblich ist.



Ich sähe da keinen Bedarf für eine zusätzliche Funktion.

Korrekt, die Designer der Java Class Lib ebenfalls nicht, darum gibt es nur die eine :D



Mir ist nicht klar, wiso man ein File Object verwenden wollte, bzw. wozu das gut ist.

Weil es eindeutig ein File beschreibt und man ohne Tricks zum Beispiel leicht feststellen kann, ob das Ziel schon existiert.



Das hiesse also, um ein File umzubenennen, muss ein neues File erzeugt werden welches alle Eigenschaften vom alten File übernimmt mit Ausnahme des Filenames.

Das neue File hat erstmal nichts mit dem alten zu tun (außer man gibt den Parent des alten als den Parent des neuen an), potentiell existiert für das neue File noch keine Repräsentation im Filesystem, also nichts "reales".



Dann ist mir immer noch nicht klar, wiso renameTo() nicht einfach nur die Info erwartet, die tatsächlich noch fehlt.

Tut es doch, es bekommt einen Datentyp, der Pfad+Name enthält :)

Ciao,
_

[RogerJFX]

Also genaugenommen ist das Umbenennen eines Files z.B. unter DOS doch nur eine Änderung in irgendeiner Registratur. Ich habe bisher immer angenommen, daß Sun einfach nicht an diese Registratur rangekommen ist.

Irgendwie habe ich das Gefühl, daß renameTo(File) erst den File kopiert (via 2er Streams, copy() gibt es schließlich auch nicht), und dann den Ursprungs-File löscht.

Also Übergabe by Value (:D), weil Referenz unbekannt ( :D :D :D ).

Wolln ma mal was dekompilieren, um das rauszufinden?

Cheers,

Roger

[peschmae]

Das musst du nicht dekompilieren um rauszufinden dass dem nicht so ist. Dazu ist nämlich der rename-Vorgang viel zu schnell mit grossen Dateien.

Ausserdem hats ja in der API sowieso entsprechende Methoden.

MfG Peschmä

[RogerJFX]

Stimmt. Das hätte ich mal testen können.

Na dann...

[anda_skoa]

Also genaugenommen ist das Umbenennen eines Files z.B. unter DOS doch nur eine Änderung in irgendeiner Registratur.

Nur innerhalb des selben Filesystems.
Ein rename dessen Ziel in einem anderen Filesystem liegt, ist ein Move, darum wird das auch oft bei diesen einfachen APIs mit einem Fehlercode oder einer Exception beantwortet, weil ein Move aufgrund der Operationsdauer besser nicht blockierend gemacht wird, die Funktion könnte ja auch in einem GUI Kontexte benutzt werden und da wäre das nicht so fein.



Ich habe bisher immer angenommen, daß Sun einfach nicht an diese Registratur rangekommen ist.

Das ist auch nicht nötig, dazu hat das Hostbetriebsystem ja eine System API.
Für ein Programm, in diesem Falle die JVM, ist es ja nicht von Bedeutung wie das Dateisystem im Detail implementiert ist.

Ciao,
_