rsync hängt nach einigen übertragenen Dateien (Bash für Windows zu FreeBSD)

Ich verwende "Bash unter Ubuntu unter Windows" von einem Windows 10 Pro-PC aus, um meine Medienbibliothek auf einem FreeBSD-Server zu sichern, der als mein NAS fungiert (auf dem NAS4Free ausgeführt wird). Früher hat das perfekt funktioniert, aber vor kurzem hat es aufgehört zu funktionieren. Da ich auf meiner Seite nichts geändert habe, glaube ich, dass die Änderung von einem der Windows-Updates stammt, nicht sicher.

In jedem Fall passiert Folgendes. Kurz nachdem einige Dateien kopiert wurden, bleibt die rsync-Übertragung hängen. Ich habe es über Nacht laufen lassen, um es zu bestätigen, und es hängt nur stundenlang. Wenn ich die Aufgabe manuell beende, indem ich STRG + C an das Terminal sende, wird eine Fehlermeldung angezeigt. Einige Zeit vergeht (ca. 30 Sekunden) und das Programm stoppt:

arnaud@CLAVAIN:~$ rsync -arv --delete --no-compress /mnt/e/Music/ arnaud@nas4free.lan:~/pool1/lolilol/music
arnaud@nas4free.lan's password:
sending incremental file list
ost/Luke Cage (Original Soundtrack Album)/
ost/Luke Cage (Original Soundtrack Album)/40. Finding Chico.m4a
ost/Luke Cage (Original Soundtrack Album)/41. I Am Carl Lucas.m4a
ost/Luke Cage (Original Soundtrack Album)/42. Crispus Attucks.m4a
ost/Luke Cage (Original Soundtrack Album)/43. Hideout.m4a
ost/Luke Cage (Original Soundtrack Album)/44. Cuban Coffee.m4a
ost/Luke Cage (Original Soundtrack Album)/45. Like a Brother.m4a
ost/Luke Cage (Original Soundtrack Album)/46. Cottonmouth's Clamp.m4a
ost/Luke Cage (Original Soundtrack Album)/47. Survival.m4a
ost/Luke Cage (Original Soundtrack Album)/48. Cottonmouth Theme.m4a
ost/Luke Cage (Original Soundtrack Album)/49. Luke Cops.m4a
ost/Luke Cage (Original Soundtrack Album)/50. Crushin' On Reva.m4a
ost/Luke Cage (Original Soundtrack Album)/51. Beloved Reva.m4a
^Crsync error: unexplained error (code 130) at rsync.c(632) [sender=3.1.0]
[sender] io timeout after 60 seconds -- exiting
arnaud@CLAVAIN:~$

Sie können sehen, wo sich das ^ C befindet. Dann sende ich die Kill-Nachricht. Dies ist der Fall, wenn die Fehler "Fehler: unerklärlicher Fehler" und "io timout" angezeigt werden.

Ich habe einen alternativen Befehl ausprobiert rsync -rltvzD --progress --delete, aber dieser erzeugt den gleichen Fehler.

Gibt es überhaupt eine Möglichkeit, dies besser zu beheben, um zu verstehen, wo das Problem liegt? Beachten Sie, dass rsync einwandfrei funktioniert, wenn ich dies auf einem lokalen Laufwerk (wie einem externen USB-Laufwerk) mache.

freebsd rsync windows-subsystem-for-linux

— Astaar
quelle

Es scheint, dass in Bezug auf rsync das Windows-Subsystem für Linux bei der Behandlung der von rsync bereitgestellten Listen fehlerhaft ist. Dies sollte gemeldet werden, und ich habe getan.

— Thomas D Dial

Haben Sie das Problem # auf Github für dieses Problem? Es wurden mehrere andere Probleme in Bezug auf rsync geöffnet, die alle behoben wurden, aber diese haben mein Problem nicht gelöst.

— Astaar

Dies sieht aus wie das Problem, das hier auf der WSL BashOnWindows Github-Seite besprochen wird: github.com/Microsoft/BashOnWindows/issues/2138

— Gerald

Interessanterweise fgist rsync für mich so lange fortgesetzt, bis es an einer anderen Datei hängt. Es scheint nicht mit großen Dateien zu tun zu haben, und -W hat dies für mich nicht gelöst.

— Rev.

das gleiche für mich ... irgendeine Idee?

— Jlanza

Antworten:

Ich hatte dieses Problem auch kürzlich (wie gestern) und was ich herausgefunden habe, ist, dass wenn ich rsyncohne Delta-Kopie ( --whole-file/-Wfür die gesamte Dateiübertragung) bin , alles perfekt funktioniert.

Ich weiß, dass es nicht die beste Lösung ist, aber eine schnelle Lösung für den Moment, bis es gepatcht ist.

— George Yammine
quelle

Dies war auch die Lösung für mich, funktioniert einwandfrei mit -W, sogar mit -z -v usw.

— Kurt Koller

Ich kann noch einen weiteren Fall überprüfen, in dem dies korrekt ist. Ubuntu 18.04 unter WSL auf 1809. Dies sollte wahrscheinlich die akzeptierte Antwort / Problemumgehung sein.

— Kurt Koller

Dieses Problem hat mich heute getroffen. Es ist immer noch nicht behoben.

— Defcronyke

Ich habe das gleiche Problem. Dies geschieht nur beim Synchronisieren großer Dateien. Ich habe eine Problemumgehung gefunden:

Wenn eine Datei nicht mehr übertragen wird, brich ich sie ab und synchronisiere dann die angehaltene Datei. Aus irgendeinem Grund funktioniert das Synchronisieren der einzelnen Dateien immer. Normalerweise muss ich dies für einige Dateien tun, bevor der ursprüngliche Rsync ausgeführt wird.

Super nervig, aber ich habe keine anderen Lösungen, als Ubuntu Bash unter Windows 10 nicht zu verwenden, was enttäuschend wäre.

Mein Setup: Synchronisieren zwischen Ubuntu unter Windows 10 und dem Ubuntu-Server von digitalocean.

— David Figatner
quelle

Ich habe seitdem rsync unter Windows Bash aufgegeben. Ich benutze jetzt unisono, um die Dateien zu synchronisieren und habe keine Hänge mehr gehabt.

— David Figatner

Es ist durchaus möglich, dass die Verhaltensänderung auf ein Windows Update zurückzuführen ist und die Standardberechtigungen ändert oder eine Funktion während des Updates deaktiviert und nicht ordnungsgemäß wieder aktiviert wird. Die Lösung von Microsoft für andere Fehler besteht darin, die WSL zu deaktivieren und wieder zu aktivieren.

Wenn Sie sicher sind, dass Sie nichts geändert haben und es nach dem Deaktivieren und erneuten Aktivieren der WSL über "Windows-Funktionen" immer noch nicht funktioniert, möchten Sie es möglicherweise als Fehler / Problem auf Microsofts Github https: // veröffentlichen github.com/Microsoft/BashOnWindows/issues

— m_krsic
quelle