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

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

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:

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

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

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