rsync - opcjavc na komputerze Mac nie działa (synchronizacja ze zdalnego serwera Linux na lokalnym komputerze Mac)

9

Chcę używać rsync do tworzenia kopii zapasowych danych ze zdalnego serwera Linux na moim lokalnym komputerze Mac. Chcę zainicjować tę operację na moim lokalnym komputerze Mac. Wszystko działa dobrze, z wyjątkiem tego, że występuje problem ze znakiem specjalnym: za każdym razem, gdy ponownie uruchamiam operację rsync (po początkowej synchronizacji), pliki ze znakami specjalnymi są najpierw usuwane, a następnie ponownie synchronizowane. O ile rozumiem, istnieje problem z różnymi zestawami znaków i wydaje się , że preferowanym rozwiązaniem jest skorzystanie z --iconvopcji:

Możesz użyć opcji rsync --iconv do konwersji między UTF-8 NFC i NFD, przynajmniej jeśli korzystasz z komputera Mac. Istnieje specjalny zestaw znaków utf-8-mac, który oznacza UTF-8 NFD. Aby skopiować pliki z komputera Mac na serwer NAS, musisz uruchomić coś takiego:

rsync -a --iconv=utf-8-mac,utf-8 localdir/ mynas:remotedir/

Spowoduje to konwersję wszystkich lokalnych nazw plików z UTF-8 NFD na UTF-8 NFC na zdalnym serwerze. Zawartość plików nie zostanie zmieniona.

Problem polega na tym, że działa to dla mnie „tylko w jeden sposób”, a mianowicie podczas synchronizacji z Maca na Linuksa. Ale chcę „przejść w drugą stronę”, tj. Zsynchronizować urządzenie Linux z komputerem Mac. Chcę zainicjować operację z mojego lokalnego komputera Mac. Ale kiedy próbuję:

rsync -av --delete --iconv=utf-8,utf-8-mac mynas:remotedir/ localdir/

Otrzymuję błąd:

iconv_open("UTF-8", "utf-8-mac") failed
rsync error: requested action not supported (code 4) at rsync.c(118) [sender=3.0.9]
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]

Nie mogę zrozumieć, dlaczego to nie działa. Moja wersja rsync na Macu została zaktualizowana z wersji 2.6.9. do 3.1.1. za pomocą Macports . Zauważ, że operacja działa wtedy, gdy I (na Macu, nota bene) zainicjuję rsync Z Maca na Linuksa:

rsync -av --delete --iconv=utf-8-mac,utf-8 localdir/ mynas:remotedir/

Ale pójście w drugą stronę „z Maca - co chcę robić - nie działa.

O dziwo, testowanie w celu zainicjowania synchronizacji z komputera z systemem Linux wyświetla ten dziwny komunikat:

rsync: on remote machine: --iconv=UTF-8-MAC: unknown option
rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-45/rsync/main.c(1333) [server=2.6.9]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

w tym, uwaga, bardzo dziwne twierdzenie [server=2.6.9], chociaż zaktualizowałem do wersji 3.1.1 na Macu. Z niektórych powodów wygląda na to, że moja maszyna linuxowa „widzi” tylko oryginalną wersję rsync na Macu.

Wszelkie sugestie dotyczące rozwiązania tego problemu?

AKTUALIZACJA 23 października : Według doskonałej sugestii @Lee Johnson (patrz poniżej) inicjowanie synchronizacji z serwera Linux działa teraz. Dla kompletności wypróbowałem teraz wszystkie kombinacje i pojawia się ciekawy wzór:

NA MAC:

DZIAŁA: Pliki z komputera Mac na system Linux

WADY: Pliki z systemu Linux na komputer Mac

NA LINUX

DZIAŁA: Pliki z systemu Linux na komputery Mac

WADY: Pliki z komputera Mac na system Linux

Innymi słowy, --iconvopcja wydaje się działać tylko w jedną stronę, z plikami z komputera lokalnego do pilota, a nie odwrotnie. Wygląda mi to na błąd, ale może w ten sposób POWINNO działać?

Czy ktoś może się tym podzielić?

Nick Szwed
źródło
1
podczas korzystania z niestandardowego rsync(np. z homebrew) na komputerze Mac i wywoływania go z systemu Linux, konieczne jest określenie poprawnej ścieżki za pomocą--rsync-path="/usr/local/bin/rsync"
meduz
Zostałem wykluczony .DS_Storez synchronizacji i z tego powodu OSX nie mógł usunąć katalogów z tymi plikami w środku. Ustawiam zestawy znaków za --iconvpomocą ścieżki rsync na komputerze Mac z --rsync-path(używam homebrew), a następnie musiałem dodać, --delete-excludedaby uparte katalogi mogły zostać usunięte.
Daniel

Odpowiedzi:

12

Po wielu eksperymentach, w dużej mierze dzięki pomocnym sugestiom @Lee Johnson, w końcu znalazłem rozwiązanie, które teraz wydaje mi się zawstydzająco oczywiste. Wiele z uwagi na komentarz, który przeczytałem podczas badania problemu, pomyślałem, że powinieneś określić zestaw znaków w kolejności transformacji; ale wydaje się, że nie jest to poprawna składnia. Raczej należy

ZAWSZE używaj --iconv=utf-8-mac,utf-8podczas inicjowania rsync z Maca, i ZAWSZE używaj do --iconv=utf-8,utf-8-macinicjowania rsync z komputera z systemem Linux, bez względu na to, czy chcę zsynchronizować pliki z komputera z systemem Mac lub Linux.

To działa jak magia!

Nick Szwed
źródło
UTF8-MAC to pseudo-zestaw znaków i nie jest dostępny per se z iconvlib w systemie Linux, nawet nie w najnowszej wersji 3.1.1 w Ubuntu 14.04 LTS. To nie działa, jeśli spróbujesz zainicjować synchronizację w systemie Linux.
Achim Lammerts
5

Czy niedawno zaktualizowałeś system do OS X Yosemite? Miałem ten sam problem, zanim przypomniałem sobie, że zaktualizowałem / usr / bin / rsync do wersji 3.1. Kiedy uaktualniłem do Yosemite, został on zastąpiony starą wersją 2.6.9.

W moim przypadku naprawiłem problem na komputerze Mac, ponownie łącząc mój rsync 3.1 z powrotem do / usr / bin:

sudo -s
cd /usr/bin
mv rsync rsync-2.6.9
ln -s /usr/local/bin/rsync .
exit
Lee Johnson
źródło
Dzięki milionowi, to rozwiązuje zagadkę, dlaczego dostałem to 2.6.9. wiadomość. (Jednak na moim Macu zainstalowana wersja Macport jest w / opt / local / bin / rsync, ale zmiana linku do tego sportu działała magicznie.) Niestety, chcę zainicjować synchronizację z mojego komputera MAC, więc to tylko pomaga mnie, o ile rozumiem, że mój komputer z systemem Linux może dowiedzieć się, co robić. Dlaczego więc nie działa po zainicjowaniu z mojego komputera Mac? Oznacza to, że „rsync -av --delete --iconv = utf-8, utf-8-mac mynas: remotedir / localdir /”
Nick The Swede
Powiem też, że niestety mam zbyt niską reputację, aby dać +1 twojej pomocnej odpowiedzi, a ponieważ nadal nie działa tak, jak tego chcę, nie mogę zaznaczyć tego jako rozwiązanego. W każdym razie złota gwiazda w mojej głowie (i obiecuję wrócić i dać +1, gdy tylko mój przedstawiciel osiągnie 15)!
Nick The Swede
Czy mówisz, że nadal nie działa od strony OS X, nawet przy uruchomionym rsync 3.x? Nie sądzę, że --iconvjest to obsługiwane w 2.6.9; nawet jeśli rsync po prostu wysyła opcję do zdalnego hosta w celu obsługi, musi rozpoznać tę opcję po stronie OS X. Co which rsync; rsync --versionci mówi z terminala OS X?
Lee Johnson
To jest poprawne. Jak widać w komunikacie o błędzie (trzeci szary cytat w pytaniu), rozpoznaje, że używam 3.1 na komputerze Mac: [Receiver = 3.1.1] i twierdzi, że akcja nie jest obsługiwana, chociaż najwyraźniej działa od strony Linuksa, a także podczas synchronizacji z komputera Mac pliki na komputerze Mac do serwera Linux. Ale z systemu Mac pliki z systemu Linux na system Mac nie działają. Tak dziwne (przynajmniej moim oczom nooba).
Nick The Swede
2
Kiedy wypróbujesz to z Linuksa, co się stanie, jeśli wymusisz ścieżkę wykonywalną za pomocą czegoś takiego jak --rsync-path=/opt/local/bin/rsyncuzyskanie znanej wersji 3.1.1 po stronie Maca?
Lee Johnson