webget – Wenn wget zu mächtig ist

Und wieder war es Zeit für ein Konsolenprogramm von codingfreaks. Ich konnte mal wieder ein Tool nicht finden. Diesmal brauchte ich eine einfache Möglichkeit, um per HTTP beliebige Dateien von einer IIS-Freigabe herunterzuladen. WebGet war geboren.

Download aktuelle Version (7Zip)

Vorbemerkungen

Ich bin mir diesmal sehr sicher, dass ich das Rad neu erfunden habe, aber ich hatte einfach keine Lust mehr, zu suchen und wenn ich schon was programmiere, dann können es auch gleich die Leser von codingfreaks bekommen. Bei mir stellte sich das Problem, dass einer meiner Server seine Sicherungen auf einem im IIS gehosteten Verzeichnis ablegen soll. Ich möchte dann den Download per HTTP vornehmen.

Warum wget versagt

Zuerst habe ich es mit wget versucht. Dem Vernehmen nach sollte das genau mein Tool sein. Das Problem ist aber gewesen, dass wget sich schlicht weigerte, das zu tun, wofür ich es brauchte. Aber eins nach dem anderen.

Nehmen wir einmal an, meine Dateien liegen auf der URL http://meinserver/downloads. Soweit so gut. Wenn ich nun immer die gleiche Datei herunterladen wollte, wäre wget wirklich cool. Ich würde einfach schreiben:

wget http://meinserver/downloads/meinedatei.zip c:\temp 

und alles würde laufen. Mein Problem ist aber nun gewesen, dass der Dateiname sich ständig ändert. Ich möchte eher sowas wie alle ZIP-Dateien herunterladen, die da sind. Auch dafür bietet wget etwas an:

wget -A.zip http://meinserver/downloads/meinedatei.zip c:\temp 

Leider kann wget das nicht oder besser gesagt: Im Zusammenspiel mit meinem IIS geht es nicht. Der Hintergrund dafür ist der, dass der IIS bei Angabe des Verzeichnisses eine eigentlich nicht vorhandene index.html ausliefert. Das ist die, die man aus dem Browser kennt, wenn man das Recht hat, den Verzeichnisinhalt zu lesen.

Wget kann nun eigentlich durch ein Dokument traversieren und alle enthaltenen Dateilinks downloaded. Das aber machte er bei mir und anderen nicht, sondern er hat mir immer wieder die index.html in mein c:\temp gepackt.

Jetzt reichts

Irgendwann reichte es dann und ich startete mein Visual Studio. 3 Stunden später war WebGet geboren. Ich habe es erstmal ganz einfach gehalten:

webget SERVERPFAD ENDUNG LOKALPFAD

oder

webget SERVERPFAD ENDUNG LOKALPFAD USER PASS

genügen und schon gehts los. Hier ein Beispiel-Screenshot:

Abb. 1: Webget in Aktion
Abb. 1: Webget in Aktion

Wo ich schonmal so weit war, habe ich gleich noch ein paar Details zur Fortschrittsdarstellung implementiert, um nicht komplett gegen wget abzustinken ;-).

.NET

Codeseitig passiert nichts Spannendes. Ich nutze vorwiegend die Klasse System.Net.WebClient. Hier kommen die Methoden OpenReadTaskAsync, DownloadFileTaskAsync in Verbindung mit async/await zum Einsatz. Meine bewährte Utility-DLL ist bereits im Download enthalten und führt ein paar Funktionen für das Consolen- und Parameterhandling durch. Ein einfaches „webget“ auf der Konsole liefert dementsprechend die Parameter-Informationen aus. Sollte Interesse am Quellcode bestehen, stelle ich das Ganze gern online.

Fazit

Das Tool ist sicher noch nicht perfekt, aber es verrichtet seinen Dienst. Bei mir ist es jedenfalls stabil im Einsatz.

6 Antworten auf „webget – Wenn wget zu mächtig ist“

  1. Stimmt… wget ist ziemlich umfangreich und es ist teilweise etwas kompliziert, die richtigen Parameter für seine Zwecke herauszufiltern und anzuwenden.

    Danke für das kleine Tool! Werde mir das mal anschauen und versuchen, in meine Projekte mit einzubinden.

    Grüße
    Sebastian

    1. Hallo Mario! Auch ’ne coole Idee. Na hoffentlich habe ich nicht die ganzen 3 Stunden umsonst verbracht! Ich sehe mir das unter diesem Aspekt mal an und ergänze ggf. den Artikel. WebDeploy hatte ich bisher nur für andere Aufgaben im Sinn. Gruß, sprinter.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.