wget startet den Download und stoppt dann "kann nicht schreiben"

13

Ich benutze wget, um einige Dateien von einem Server auf einen anderen zu spiegeln. Ich benutze den folgenden Befehl:

wget -x -N -i http://domain.com/filelist.txt

-x = Weil ich die Verzeichnisstruktur beibehalten möchte

-N = Zeitstempel, um nur neue Dateien zu erhalten

-i = Um eine Liste von Dateien von einer externen Datei herunterzuladen, eine in jeder Zeile.

Kleine Dateien wie eine, die ich teste und die 326 KB groß ist, sind in Ordnung.

Aber eine andere mit 5 GB lädt nur 203 MB herunter und stoppt dann (es sind immer 203 MB, die ein paar Kilobyte geben oder nehmen).

Die angezeigte Fehlermeldung lautet:

Es kann nicht in "path / to / file.zip" geschrieben werden

(Ich bin mir nicht sicher, warum es die seltsamen Zeichen davor und danach gibt. Ich verwende Putty in Windows und dies kann oder kann nichts damit zu tun haben, also habe ich sie drin gelassen. Ich nehme aber nicht an.)

Die vollständige Antwort lautet wie folgt: (Ich habe Pfade, IP und Domainnamen ersetzt.)

--2012-08-31 12: 41: 19-- http://domain.com/filelist.txt Auflösung von domain.com ... MY_IP Verbindung zu domain.com | MY_IP |: 80 ... hergestellt. HTTP-Anfrage gesendet, Antwort wird erwartet ... 200 OK Länge: 161 [text / plain] Server-Datei nicht neuer als lokale Datei "domain.com / filelist.txt"

--2012-08-31 12: 41: 19-- http://domain.com/path/to/file.zip Verbindung zu domain.com wird hergestellt | MY_IP |: 80 ... hergestellt. HTTP-Anfrage gesendet, Antwort wird erwartet ... 200 OK Länge: 5502192869 (5.1G) [application / zip] Die Größen stimmen nicht überein (lokal 213004288) - Abrufen.

--2012-08-31 12: 41: 19-- http://domain.com/path/to/file.zip Verbindung zu domain.com wird hergestellt | MY_IP |: 80 ... hergestellt. HTTP-Anfrage gesendet, Antwort wird erwartet ... 200 OK Länge: 5502192869 (5.1G) [application / zip] Speichern unter: âdomain.com / path / to / file.zipâ

3% [====>
] 213.003.412 8,74 M / s in 24 s

Es kann nicht in âdomain.com / path / to / file.zipâ geschrieben werden

Es scheint keinen Unterschied zu machen, ob das Pfadverzeichnis bereits vorhanden ist oder direkt erstellt wird.

Hat jemand eine Idee, warum es aufhört und wie ich es beheben kann?

Jede Hilfe mit am meisten geschätzt werden.

EDIT: Ich habe auch versucht nur ein wget zu machen, keine Dateieingabe und die Datei umzubenennen. Diesmal lädt es etwas mehr als 3GB herunter und gibt dann gleich keinen Schreibfehler aus.

wget -x -N http://domain.com/path/to/file.zip -O files/bigfile.zip

linux file-permissions wget

— John Mellor
quelle

Hast du Sonderzeichen auf deinem Weg?

— JMeterX

Funktioniert es wie erwartet, wenn Sie "cd / tmp &&" vor dem Befehl eingeben?

Ist Ihre Festplatte voll?

— Jenny D

Die Festplatte ist definitiv nicht voll und es gibt keine Sonderzeichen. Obwohl der Pfad 87 Zeichen lang ist, hat Googeln einige Probleme mit langen Namen gezeigt (der Dateiname ist jedoch nur 29 Zeichen lang). In tmp schlägt dies genauso fehl.

— John Mellor

@FreezeDriedPop Da Ihr Dateiname relativ lang ist, können Sie die -OOption so ändernwget -O test.zip http://link

— JMeterX

6

Sie erhalten diese Fehlermeldung, wenn Sie keinen Speicherplatz mehr haben. Führen Sie df aus und Sie werden sehen, ob das Verzeichnis, in das Sie schreiben, 100% ist.

— Sonne
quelle

4

Es ist ein Problem mit langer URL. Ich habe es auch gesehen. Also habe ich bit.ly benutzt und die URL verkürzt. Klappt wunderbar!

— Namchester
quelle

Bist du sicher? Es ist unwahrscheinlich, dass der Download zu einem Zeitpunkt gestartet und abgebrochen wird, zu dem das Problem mit der URL zusammenhängt, die nur zu Beginn der Transaktion verwendet wird.

— Felix Frank

Ja. Ich hatte das gleiche problem Versuch es.

— Namchester

Ich denke das Problem ist, dass Linux die lange URL nicht erkennen kann.

— Namchester

Ich nehme an, du meinst die Muschel? Weil der Kernel an diesem Versagen definitiv unschuldig ist. Selbst für die Shell ist dies nicht wahrscheinlich, aber wenn dies der Fall wäre, könnte der Download nicht einmal gestartet werden - die Shell würde fehlerhaft sein, bevor der potenzielle wgetProzess überhaupt abgebrochen wird.

— Felix Frank

1

Für mich war es wget http://dltr.org/skin/frontend/lowes/default/css/custom.css?001

— Abfragezeichenfolge

1

Ich -habe dem tarBefehl nach der Pipe nach wget ein hinzugefügt

ich hatte

wget https://example.com/path/to/file.tar.gz -O -|tar -xzf -C /path/to/file

dann änderte es zu

wget https://example.com/path/to/file.tar.gz -O - | tar -xzvf - -C /path/to/file

— shadi
quelle

Vergessen Sie nicht das `-` auch für Teer :).

— Shital Shah

0

Wenn es anfängt, eine große Datei zu speichern und 203 MB davon schreibt, würde ich vermuten, dass Sie entweder ein vollständiges Dateisystem auf der empfangenden Seite haben oder die Netzwerkverbindung eine Zeitüberschreitung aufweist.

Sie können df -h auf dem empfangenden Server verwenden, um festzustellen, ob das Dateisystem voll ist

Überprüfen Sie diese Antwort auf Timeout-Probleme mit wget:

/programming/2291524/does-wget-timeout

Versuchen Sie außerdem erneut, die fehlgeschlagene Übertragung durchzuführen, und lassen Sie die Option -N timestamp aus

Führen Sie außerdem ulimit -a aus, um festzustellen, ob auf dem empfangenden Server eine Dateigrößenbeschränkung vorliegt

— Verärgerter Benutzer
quelle

Ich bin kein Experte, aber ich glaube, es läuft unter CentOS 6. Außerdem bin ich mir nicht sicher, wie ich die Darstellung der Zeichen überprüfen soll. Zwar wird der Download gestartet und andere kleinere Dateien werden heruntergeladen, aber ich glaube nicht, dass dies das Problem ist.

— John Mellor

Haben die Dateien, die erfolgreich heruntergeladen werden konnten, ALLE lustigen Zeichen im Namen?

— DisgruntledUser

Nein, überhaupt keine seltsamen Zeichen, es sei denn, ein Punkt ist ein seltsames Zeichen, z. B. "megapack_4.11.zip". Aber wieder habe ich es einfach mit dem Namen "bigfile.zip" versucht und das gleiche Problem tritt auf.

— John Mellor

Vielleicht ist es nur Putty, das auf eine andere Zeichenrepräsentation als UTF-8 eingestellt ist

— DisgruntledUser

Ja, ich glaube wirklich nicht, dass das das Problem ist. Ich habe es gerade erwähnt, als ich von Putty kopiert und eingefügt habe. Das eigentliche Problem, an das nicht geschrieben werden kann.

— John Mellor

0

Endlich habe ich es herausgefunden und es war ein Platzproblem. Es ist ein Problem mit 1and1 Cloud Servern, mehr dazu hier: http://www.mojowill.com/geek/1and1-dynamic-cloud-server-disk-allocation/

— John Mellor
quelle

0

Ich habe etwas Ähnliches gemacht wie:

wget -x -N -i http://domain.com/filelist.txt

Ich erhielt:

--2016-12-09 07:44:23--  https://www.example.com/dir/details?abc=123&def=456
Resolving www.example.com (www.example.com)... 1.2.3.4
Connecting to www.example.com (www.example.com)|1.2.3.4|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
details?abc=123&def=456: No such file or directory

Cannot write to ‘details?abc=123&def=456’ (Success).

In meiner entsprechenden Datei filelist.txt hatte ich eine URL wie:

https://www.example.com/dir/details?abc=123&def=456

Zum Debuggen habe ich versucht, dieselbe Datei zu erstellen, die wget zu erstellen versucht hat:

touch "details?abc=123&def=456"
touch: cannot touch ‘details?abc=123&def=456’: No such file or directory

Viola! Es sieht so aus, als wäre das ?das Problem, aber es empfiehlt sich, alle Sonderzeichen aus den Dateinamen zu entfernen &.

— nikc
quelle