Herangehensweise: FTP-Transfer von Verzeichnis

[jollyroger]

Moin moin,

mir geht es hier weniger um eine komplette Implementierung sondern eher um die beste Herangehensweise.


Zur Vorgeschichte:

Ich möchte folgendes realisieren:

Eine Java-Applikation, die periodisch Verzeichnisse scannt und dann - abhängig von Filenamens-Mustern - diese Dateien auf einen FTP-Server übertragt.

Da diese Applikation teil einer größeren ist, ist periodisches Scannen usw (mittels Quartz etc) schon erledigt, mir geht es hier nur um den FTP-Transfer als solches.

Ich verwende dazu das org.apache.commons.net-Paket.

Zur Frage:

Soweit ich das nun überblicken kann, bietet org.apache.commons.net keine Möglichkeit komplette Verzeichnisse zu übertragen.
Dabei kann das ja ganz schön "tricky" werden.

Verzeichnis einlesen, ggf. auf dem Server anlegen, rekursiv durchgehen, die ganze Strukturen dabei merken usw.

Ich denke mal mit error-handling usw. wird das doch recht schnell komplex und damit fehleranfällig.

Wie würdet ihr an so was herangehen? Gibt es noch gute Bibliotheken die mir z.B. das rekursive Traversieren von Verzeichnissen abnehmen?

DirectoryWalker aus org.apache.commons.io sieht ja recht vielversprechend aus, gibt es evtl. noch Libs die mir noch etwas mehr abnehmen können?

-> http://www.jscape.com/sftp/index.html bietet genau was ich will, kostet aber leider Geld was nicht mehr im Budget ist....

Any ideas?

 

[SnooP]

Wenn man Rekursion verstanden hat, sollte das ganze ein greifbares Problem sein ehrlich gesagt ... dadurch, dass Verzeichnisstrukturen immer einfache Baumstrukturen sind und du keine Zyklen etc. hast, kann man das doch relativ einfach erledigen.

Meines Wissens kann FTP selbst auch gar nicht sowas wie Verzeichnisse übertragen, sondern macht immer alles einzeln (erkennbar auch bei den clients, die das verzeichnis übertragen und dann nach und nach alle subcontents).

Wenn du den Transfer in eine Transaktion gießt, dann kannst du auch alles wieder einsammeln .. letztlich brauchst du auch eine Funktion zum rekursiven Verzeichnisse löschen, was im Fehlerfall losgeht, um unvollständig übertragene Daten wieder zu killen.

 

[jollyroger]

Ja, Rekursion usw ist nicht "das" Problem, ich denke halt nur das es doch recht viel Code wird.

Generell nehme ich dann lieber Komponenten bei denen man davon ausgehen kann, das sie bugfrei sind.

Es wäre halt schon gewesen, eine API zu haben, die sowas bietet wie:

public void upload(String localdir, String remoteDir) throws.....

bzw.

public void download(String localdir, String remoteDir) throws.....

Da ich allerdings weder über google noch bei sourceforge etwas gefunden habe, was:

-> nicht steinalt ist
-> kostenlos ist und open-source

werde ich das wohl doch selber implementieren müssen.

Evtl. kennt noch jemand eine gute Alternative zum selber implementieren?

 

[Leroy42]

Prinzipielle Vorgehensweise:

public void upload(String localdir, String remoteDir) {upload(new File(localdir), remoteDir);}
public void upload(File localdir, String remoteDir) {
  // wenn remoteDir nicht existiert ==> anlegen
  for (File f : localDir.listFiles())
    if (f.isDirectory())
      upload(f, remoteDir+"/"+f.name());
    else
      // f auf remoteDir+"/"+f.name() uploaden
}

Das downloaden ist etwas komplizierter, da es bei
FTP kein listFiles() gibt und man sich das selbst basteln muss.

 

[jollyroger]

Leute,

danke erst mal für die Hinweise....

Ich bin etwas überrascht, ich hätte gedacht da gäbe es schon was....

Aktuell stehe ich vor folgendem Problem:

Wie krieg ich denn bei einem download vorher raus, ob die Datei ASCII oder binär ist?

Ich gehe doch recht in der Annahme, das eine im Binär-Mode runtergeladene Datei futsch ist und umgedreht eben so, oder?

Irgendwie sehe ich beim Jakarta-Client keine Möglichkeit das vorher festzustellen, wahrscheinlich geht das auch nicht?

Wie machen das dann ftp-clients? Die setzen das doch auch ohne Zutun, und ich hab noch nie erlebt, das da eine Datei futsch war.....

 

[Murray]

Wie krieg ich denn bei einem download vorher raus, ob die Datei ASCII oder binär ist?

Wenn man das einer Datei "ansehen" könnte, dann würde das sicherlich im Protokoll bereits behandelt werden - man muss das vor dem Transfer angeben, weil das eben nur der Anwender wissen kann.

Ich gehe doch recht in der Annahme, das eine im Binär-Mode runtergeladene Datei futsch ist und umgedreht eben so, oder?

Der Binärmodus bei FTP bedeutet, dass die Datei unverändert übertragen wird (das will man in den allermeisten Fällen); auch reine Textdateien kann man ruhig so übertragen.

 

[jollyroger]

Der Binärmodus bei FTP bedeutet, dass die Datei unverändert übertragen wird (das will man in den allermeisten Fällen); auch reine Textdateien kann man ruhig so übertragen.

Hui!

Vielen Dank für die Aufklärung, dann bin ich ja beruhigt.... :wink:

Dennoch stellt sich mir dann die Frage: Wieso kann / sollte man dann überhaupt was am Übertragungsmodus ändern?
Anders formuliert: Wenn der Binärmodus bei FTP bedeutet, dass die Datei unverändert übertragen wird, wieso gibt es dann überhaupt sowas wie ASCII-Modus?

Ich möchte doch, das die Datei durch die Übertragung eben nicht verändert wird, oder sehe ich hier was falsch?

 

[jollyroger]

Der Binärmodus bei FTP bedeutet, dass die Datei unverändert übertragen wird (das will man in den allermeisten Fällen); auch reine Textdateien kann man ruhig so übertragen.

Hui!

Vielen Dank für die Aufklärung, dann bin ich ja beruhigt.... :wink:

Dennoch stellt sich mir dann die Frage: Wieso kann / sollte man dann überhaupt was am Übertragungsmodus ändern?
Anders formuliert: Wenn der Binärmodus bei FTP bedeutet, dass die Datei unverändert übertragen wird, wieso gibt es dann überhaupt sowas wie ASCII-Modus?

Ich möchte doch, das die Datei durch die Übertragung eben nicht verändert wird, oder sehe ich hier was falsch?

 

[Murray]

Bin jetzt kein Experte für das FTP-Protokoll, aber m.w. werden im ASCII-Modus die unterschiedlichen Zeilentrenner- und Dateiende-Zeichen automatisch angepasst (sofern Client und Server auf unterschiedlichen Betriebssystemen laufen). Außerdem macht man sich die Tatsache zunutze, dass ein ASCII-Zeichen mit 7 Bit dargestellt werden kann, so dass im Text-Modus das höchstwertige Bit nicht mit übertragen werden muss; man kommt also mit etwas weniger Traffic aus.