Jakiś czas temu musiałem zrozumieć dane rsyncwyjściowe skryptu, który pisałem. Podczas pisania tego scenariusza przeszukałem go i doszedłem do tego, co @mit napisał powyżej . Wykorzystałem te informacje, a także dokumentację z innych źródeł, do stworzenia własnego podkładu na temat flag bitowych i sposobu uzyskania rsyncflag bitowych dla wszystkich akcji (domyślnie nie robi tego).
Publikuję tutaj te informacje w nadziei, że pomogą one innym, którzy (tak jak ja) natkną się na tej stronie za pośrednictwem wyszukiwania i potrzebują lepszego wyjaśnienia rsync.
Dzięki połączeniu z --itemize-changesflagą i z -vvvflagą, rsyncdaje nam szczegółową wyjście wszystkich zmian systemu plików, które zostały zidentyfikowane w katalogu ze źródłami w porównaniu do katalogu docelowego. Flagi bitowe utworzone przez rsyncmożna następnie zdekodować, aby określić, co się zmieniło. Aby zdekodować znaczenie każdego bitu, skorzystaj z poniższej tabeli.
Wyjaśnienie pozycji każdego bitu i wartości w rsyncwyjściu:
YXcstpoguax path/to/file
|||||||||||
||||||||||╰- x: The extended attribute information changed
|||||||||╰-- a: The ACL information changed
||||||||╰--- u: The u slot is reserved for future use
|||||||╰---- g: Group is different
||||||╰----- o: Owner is different
|||||╰------ p: Permission are different
||||╰------- t: Modification time is different
|||╰-------- s: Size is different
||╰--------- c: Different checksum (for regular files), or
|| changed value (for symlinks, devices, and special files)
|╰---------- the file type:
| f: for a file,
| d: for a directory,
| L: for a symlink,
| D: for a device,
| S: for a special file (e.g. named sockets and fifos)
╰----------- the type of update being done::
<: file is being transferred to the remote host (sent)
>: file is being transferred to the local host (received)
c: local change/creation for the item, such as:
- the creation of a directory
- the changing of a symlink,
- etc.
h: the item is a hard link to another item (requires
--hard-links).
.: the item is not being updated (though it might have
attributes that are being modified)
*: means that the rest of the itemized-output area contains
a message (e.g. "deleting")
Przykładowe dane wyjściowe rsync dla różnych scenariuszy:
>f+++++++++ some/dir/new-file.txt
.f....og..x some/dir/existing-file-with-changed-owner-and-group.txt
.f........x some/dir/existing-file-with-changed-unnamed-attribute.txt
>f...p....x some/dir/existing-file-with-changed-permissions.txt
>f..t..g..x some/dir/existing-file-with-changed-time-and-group.txt
>f.s......x some/dir/existing-file-with-changed-size.txt
>f.st.....x some/dir/existing-file-with-changed-size-and-time-stamp.txt
cd+++++++++ some/dir/new-directory/
.d....og... some/dir/existing-directory-with-changed-owner-and-group/
.d..t...... some/dir/existing-directory-with-different-time-stamp/
Przechwytywanie rsyncwyjścia (skupione na flagach bitowych):
W moim eksperymentów zarówno --itemize-changesflag i-vvv flagi są potrzebne, aby dostać się rsyncdo wyjścia wpis dla wszystkich zmian w systemie plików. Bez -vvvflagi triple verbose ( ) nie widziałem listy zmian katalogu, łącza i urządzenia. Warto poeksperymentować z wersją rsync, aby upewnić się, że obserwuje i odnotowuje wszystko, czego się spodziewałeś.
Jednym z przydatnych zastosowań tej techniki jest dodanie --dry-runflagi do polecenia i zebranie listy zmian, określonej przez rsync, w zmiennej (bez dokonywania żadnych zmian), aby można było samodzielnie wykonać pewne przetwarzanie listy. Coś podobnego do poniższego przechwyciłoby dane wyjściowe w zmiennej:
file_system_changes=$(rsync --archive --acls --xattrs \
--checksum --dry-run \
--itemize-changes -vvv \
"/some/source-path/" \
"/some/destination-path/" \
| grep -E '^(\.|>|<|c|h|\*).......... .')
W powyższym przykładzie wyjście (stdout) z rsyncjest przekierowywane do grep(przez stdin), więc możemy izolować tylko te wiersze, które zawierają flagi bitowe.
Przetwarzanie przechwyconych danych wyjściowych:
Zawartość zmiennej można następnie rejestrować w celu późniejszego wykorzystania lub natychmiastowo iterować pod kątem interesujących nas elementów. Używam dokładnie tej taktyki w scenariuszu, o którym pisałem podczas badania rsync. Możesz spojrzeć na skrypt ( https://github.com/jmmitchell/movestough ), aby zobaczyć przykłady przetwarzania końcowego przechwyconych danych wyjściowych w celu wyodrębnienia nowych plików, zduplikowanych plików (ta sama nazwa, ta sama zawartość), kolizji plików (ta sama nazwa, różne zawartość), a także zmiany w strukturze podkatalogów.