Lombak Geschrieben 21. April 2008 Teilen Geschrieben 21. April 2008 Hoi zusammen Ich hab noch wenig Java Erfahrung und will ein kleines Programm schreiben das ich in meine Web Application integrieren will. Ich will nun ein Programm schrieben das mir ein Verzeichniss mit dem Inhalt Verschiebt und die alten daten löscht. Folgendermassen solte das gehen: Quellverzeichniss: c:\slt\packages\soft\test.zip, test2.zip, file1.zip Zielverzeichniss:: c:\sld\packages\ Also im Quellverzeichniss liegen 3 zip dateien die ich verschieben will mit dem Verzeichniss soft. Es sollte danach folgendermassen aussehen: Quellverzeichniss: c:\slt\packages\ Zielverzeichniss:: c:\sld\packages\soft\test.zip, test2.zip, file1.zip Und das ganze muss auf einer UNIX machine laufen, da ich mich mit den Unix Commands nicht auskenne und bei Java ganz am Anfang bin, würde ich mich riesig über alle möglichen Antworten freuen. Ich danke schon im voraus und entschuldige mich für auch schon im voraus für Unklarheiten falls diese bestehen. mfg lomb Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
geloescht_Newlukai Geschrieben 21. April 2008 Teilen Geschrieben 21. April 2008 Du schreibst Dir am besten eine Methode, der Du die Quell- und Zieldatei in Form von File-Objekten übergibst. Die Zieldatei existiert evtl. noch nicht, aber das kannst Du prüfen und sie erstellen. Dann öffnest Du beide Dateien (Quelle zum Lesen, Ziel zum Schreiben) und schaufelst, am besten gepuffert, die Daten rüber. Beide Dateien schließen und fertig. Das machst Du dann für jede zu kopierende Datei. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Amstelchen Geschrieben 21. April 2008 Teilen Geschrieben 21. April 2008 ich frage mich an dieser stelle, warum man dateien beim verschieben zum lesen und schreiben öffnen muss - es gibt doch methoden in java.io, z.b. copyfile, copydirectory, delete. alles, was rekursiv verschoben werden soll, kann ja in einer rekursiven funktion stattfinden. und ich bezweifle, dass unixoide OS pfade wie c:\slt\ kennen. s'Amstel Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
speedi Geschrieben 22. April 2008 Teilen Geschrieben 22. April 2008 es gibt doch methoden in java.io, z.b. copyfile, copydirectory, delete. Da ich neulich erst ein ganz ähnliches Problem hatte (kopieren von Dateien aller Art) bin ich mir ziemlich sicher, dass JAVA keine Methoden wie "copyfile" "copydirectory" und "delete" hat. Aber da ich mir nur "ziemlich sicher" bin kannst mir mal sagen welche Klasse diese Methoden bereitstellen würde? Ich verfolge das Thema hier mit eigenem sehr großen Interesse, vor allem das Löschen von Dateien mit JAVA würde mich interesieren. @Threadstarter: Beim kopieren musst du drauf achten NICHT über FileWriter und FileReader zu gehen und diese dann mittels eines BufferedWriters zu handeln. Sondern nimm FileInputStream und FileOutputStream. Sonst kanns passieren dass auf der anderen Seite was anderes rauskommt als du einliest. Bei mir konnte ich danach die kopierten Programme oder Multimediadateien nicht mehr öffnen/ausführen. Aber achte darauf, dass du wie Newlukai schon gesagt hat trotzdem bufferst. Bei einer Zeichenweisen Variante bricht sonst die Perfomance ein. Eine denkbare Variante wäre z.B. das hier: try { FileInputStream in = new FileInputStream(source); FileOutputStream out = new FileOutputStream(destination); int i; while((i = in.read(buffer))!=-1){ out.write(buffer, 0, i); } in.close(); out.close(); } catch (IOException e) { System.err.println("Could not copy File " + source.getAbsolutePath() + " to " + destination.getAbsolutePath() + "."); } //buffer ist in meinem Fall ein statisches byte[] mit der Größe 10485760 (also 10 MB) Am perfomantesten wäre es allerdings wahrscheinlich wenn du mit Runtime.getRuntime.execute(String command) die Aufgabe einfach an dein Betriebssystem übergibst. Damit verlierst du allerdings die Plattformunabhängigkeit. Ich kenn mich leider mit Unix-Betriebssystemen nicht so aus, deshalb weiß ich jetzt nicht wie der Kommandozeilenbefehlt zum verschieben/kopieren/löschen da heißt aber das rauszufinden sollte für dich denke ich kein Problem darstellen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
TDM Geschrieben 22. April 2008 Teilen Geschrieben 22. April 2008 Da ich neulich erst ein ganz ähnliches Problem hatte (kopieren von Dateien aller Art) bin ich mir ziemlich sicher, dass JAVA keine Methoden wie "copyfile" "copydirectory" und "delete" hat. Aber da ich mir nur "ziemlich sicher" bin kannst mir mal sagen welche Klasse diese Methoden bereitstellen würde? Ich verfolge das Thema hier mit eigenem sehr großen Interesse, vor allem das Löschen von Dateien mit JAVA würde mich interesieren. @Threadstarter: Beim kopieren musst du drauf achten NICHT über FileWriter und FileReader zu gehen und diese dann mittels eines BufferedWriters zu handeln. Sondern nimm FileInputStream und FileOutputStream. Sonst kanns passieren dass auf der anderen Seite was anderes rauskommt als du einliest. Bei mir konnte ich danach die kopierten Programme oder Multimediadateien nicht mehr öffnen/ausführen. Aber achte darauf, dass du wie Newlukai schon gesagt hat trotzdem bufferst. Bei einer Zeichenweisen Variante bricht sonst die Perfomance ein. Eine denkbare Variante wäre z.B. das hier: try { FileInputStream in = new FileInputStream(source); FileOutputStream out = new FileOutputStream(destination); int i; while((i = in.read(buffer))!=-1){ out.write(buffer, 0, i); } in.close(); out.close(); } catch (IOException e) { System.err.println("Could not copy File " + source.getAbsolutePath() + " to " + destination.getAbsolutePath() + "."); } //buffer ist in meinem Fall ein statisches byte[] mit der Größe 10485760 (also 10 MB) Ich würde hier eher zu nio tendieren. (schneller und so): public static void copyFile(File in, File out) throws IOException { FileChannel inChannel = new FileInputStream(in).getChannel(); FileChannel outChannel = new FileOutputStream(out).getChannel(); try { int maxCount = (64 * 1024 * 1024) - (32 * 1024); long size = inChannel.size(); long position = 0; while (position < size) { position += inChannel.transferTo(position, maxCount, outChannel); } catch (IOException e) { throw e; } finally { if (inChannel != null) inChannel.close(); if (outChannel != null) outChannel.close(); } } :hells: Am perfomantesten wäre es allerdings wahrscheinlich wenn du mit Runtime.getRuntime.execute(String command) die Aufgabe einfach an dein Betriebssystem übergibst. Damit verlierst du allerdings die Plattformunabhängigkeit. Ich kenn mich leider mit Unix-Betriebssystemen nicht so aus, deshalb weiß ich jetzt nicht wie der Kommandozeilenbefehlt zum verschieben/kopieren/löschen da heißt aber das rauszufinden sollte für dich denke ich kein Problem darstellen. mv (move) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
speedi Geschrieben 28. April 2008 Teilen Geschrieben 28. April 2008 Muss ich mir gleich mal anschauen. Bei FileInputStream ist die Performance echt zum Teil grauenhaft. Wenn ein oberklasse Dualcore beim einfachen Datei-kopieren auf 20%-40% CPU last ist, läuft irgendwas nämlich definitiv nicht optimal. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
geloescht_Newlukai Geschrieben 28. April 2008 Teilen Geschrieben 28. April 2008 Und warum? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 28. April 2008 Teilen Geschrieben 28. April 2008 Weil das Kopieren normalerweise komplett an der CPU vorbeigehen sollte. Das funktioniert aber nur, wenn das OS auch weiß, dass es eine Datei einfach auf der Platte kopieren soll. Beim Verschieben innerhalb einer Partition wird die Datei an sich z.B. auch nicht angefasst sondern nur Metainformationen im Filesystem geändert (darum geht das auch sehr schnell). Über einen Stream hat man diese Möglichkeit natürlich nicht. Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
baba007 Geschrieben 28. April 2008 Teilen Geschrieben 28. April 2008 kuck kuck customized buffer Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 28. April 2008 Teilen Geschrieben 28. April 2008 Ja das mag alles sein, trotzdem les ich da nirgends, dass hier ein direkter Zugriff auf die Controllerlogik gemacht wird. Sprich java verwendet keine Betriebssystemroutinen wie sie z.B. die glibc bietet. Es geht nicht darum die Dateien so gut es geht im RAM zu puffern - es geht darum sie überhaupt nicht Puffern zu müssen sondern alles dem Controller zu überlassen. dann wird auch die CPU nicht belastet. Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
baba007 Geschrieben 28. April 2008 Teilen Geschrieben 28. April 2008 mit java auf auf hardware zugreifen? in einer JVM? Dann sind wir wieder bei embedded C oder ähnlichem... da bleibe ich lieber bei java pur und achte auf den speicher Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 29. April 2008 Teilen Geschrieben 29. April 2008 Es ging ja hier auch um die Geschwindigkeit die man erreichen kann. Und in solchen Fällen ist Java eben unterlegen. Egal wieviele gepufferte Steams man inneinander verschachtelt. Es sei den, man macht es über JNI und schreibt eine kleine C Dll die den syscall durchführt. Wenn es um Performance geht, wird man in manchen Bereichen nicht drumherumkommen. Ideal wär natürlich, wenn das JDK bereits selbst so eine Möglichkeit hätte. Wär ja nichts neues. arraycopy ist ja auch in assembler implementiert und greif direkt auf den Speicher zu. Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
geloescht_Newlukai Geschrieben 29. April 2008 Teilen Geschrieben 29. April 2008 Weil das Kopieren normalerweise komplett an der CPU vorbeigehen sollte. Das funktioniert aber nur, wenn das OS auch weiß, dass es eine Datei einfach auf der Platte kopieren soll. Beim Verschieben innerhalb einer Partition wird die Datei an sich z.B. auch nicht angefasst sondern nur Metainformationen im Filesystem geändert (darum geht das auch sehr schnell). Über einen Stream hat man diese Möglichkeit natürlich nicht. Dim Klingt einleuchtend. Habe ich so noch nicht betrachtet. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.