Algum tempo atrás, eu precisava entender a rsyncsaída de um script que estava escrevendo. Durante o processo de escrever esse script, pesquisei no Google e descobri o que @mit havia escrito acima . Usei essas informações, bem como a documentação de outras fontes, para criar meu próprio primer sobre os sinalizadores de bits e como obter rsyncsinalizadores de bits de saída para todas as ações (isso não é feito por padrão).
Estou postando essa informação aqui na esperança de que ajude outras pessoas que (como eu) tropeçam nesta página por meio de pesquisa e precisam de uma explicação melhor rsync.
Com a combinação do --itemize-changessinalizador e do -vvvsinalizador, rsyncnos dá uma saída detalhada de todas as alterações do sistema de arquivos que foram identificadas no diretório de origem em comparação com o diretório de destino. Os sinalizadores de bits produzidos por rsyncpodem ser decodificados para determinar o que mudou. Para decodificar o significado de cada bit, use a tabela a seguir.
Explicação de cada posição de bit e valor na rsyncsaída de:
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")
Alguns exemplos de saída de rsync para vários cenários:
>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/
Capturando rsynca saída (com foco nos sinalizadores de bits):
Em minha experiência, tanto o --itemize-changessinalizador quanto o -vvvsinalizador são necessários para obter rsynca saída de uma entrada para todas as alterações do sistema de arquivos. Sem o -vvvsinalizador triple verbose ( ), eu não estava vendo as alterações de diretório, link e dispositivo listadas. Vale a pena experimentar sua versão do rsync para ter certeza de que está observando e anotando tudo o que você esperava.
Um uso prático dessa técnica é adicionar o --dry-runsinalizador ao comando e coletar a lista de alterações, conforme determinado por rsync, em uma variável (sem fazer alterações) para que você mesmo possa fazer algum processamento na lista. Algo como o seguinte capturaria a saída em uma variável:
file_system_changes=$(rsync --archive --acls --xattrs \
--checksum --dry-run \
--itemize-changes -vvv \
"/some/source-path/" \
"/some/destination-path/" \
| grep -E '^(\.|>|<|c|h|\*).......... .')
No exemplo acima, a saída (stdout) de rsyncé redirecionada para grep(via stdin) para que possamos isolar apenas as linhas que contêm sinalizadores de bit.
Processando a saída capturada:
O conteúdo da variável pode então ser registrado para uso posterior ou iterado imediatamente para itens de interesse. Eu uso essa tática exata no roteiro que escrevi durante a pesquisa sobre rsync. Você pode olhar o script ( https://github.com/jmmitchell/movestough ) para exemplos de pós-processamento da saída capturada para isolar novos arquivos, arquivos duplicados (mesmo nome, mesmo conteúdo), colisões de arquivos (mesmo nome, diferente conteúdo), bem como as alterações nas estruturas de subdiretórios.