- Em uma situação em que a ferramenta de sincronização de arquivos integrada ao macOS ainda se baseava em uma versão de 2006, a Apple substituiu o rsync 2.6.9 pelo openrsync
- O rsync existente no macOS recebia as correções necessárias para problemas de segurança e outros problemas, mas não incluía os recursos do rsync 3.x posteriores à versão 2.6.9
- O principal motivo da mudança é a diferença de licença: o rsync 2.x é distribuído sob a GPLv2, enquanto o rsync 3.x é distribuído sob a GPLv3
- O openrsync é compatível com o rsync, mas oferece suporte a apenas parte dos argumentos de linha de comando, portanto scripts existentes podem não funcionar sem alterações no Sequoia
- A partir do macOS 15.4,
/usr/bin/rsync aponta para o openrsync, então administradores de Mac devem verificar as opções suportadas e a compatibilidade das automações existentes
O rsync 2.6.9 que permaneceu por muito tempo no macOS
- rsync é uma ferramenta de linha de comando para transferir e sincronizar arquivos em sistemas operacionais do tipo Unix
- Pode ser usada entre dispositivos de armazenamento conectados diretamente ao mesmo computador
- Também pode ser usada para sincronizar arquivos com outros computadores na rede
- O macOS incluiu o rsync por muito tempo, mas a versão fornecida pela Apple era o rsync 2.6.9, a última versão do rsync 2.x
- O rsync 2.6.9 foi lançado em novembro de 2006, e a Apple não atualizou o rsync do macOS para uma versão posterior mesmo depois do lançamento do rsync 3.x
- A Apple forneceu as atualizações necessárias para problemas de segurança e outros problemas no rsync 2.6.9 incluído no macOS
- No entanto, até antes do macOS Sequoia, o rsync da Apple tinha uma base de quase 20 anos e não incluía os novos recursos adicionados às versões do rsync posteriores à 2.6.9
A estagnação de versão causada pela GPLv2 e GPLv3
- O rsync 2.x e o 3.x são distribuídos sob versões diferentes da licença GPL
- A Apple considerou que podia cumprir os termos da GPLv2 do rsync 2.x, mas concluiu que não podia cumprir os termos da GPLv3 do rsync 3.x
- Por esse motivo, o rsync 3.x não foi fornecido no macOS
A mudança para openrsync no macOS Sequoia
- No macOS Sequoia, a Apple substituiu o rsync 2.6.9 pelo openrsync
- openrsync é uma implementação do rsync que não usa licença GPL
- O openrsync é distribuído sob a ISC license, uma das licenças da família BSD
- A ISC license é uma licença permissiva, que impõe restrições mínimas ao uso, modificação e distribuição do software ao qual se aplica
- A Apple considerou que, ao contrário dos termos da GPLv3 do rsync 3.x, podia cumprir os termos de licença do openrsync
Diferenças de compatibilidade importantes para administradores de Mac
- Daqui em diante, a Apple pode fornecer versões atualizadas do openrsync sem se preocupar com questões de conformidade com a GPL do rsync
- A maior mudança prática é que, embora o openrsync seja compatível com o rsync, ele aceita apenas parte dos argumentos de linha de comando do rsync
- Recursos do rsync que funcionavam no macOS existente podem falhar no macOS Sequoia
- Isso porque esses recursos podem não existir na ferramenta de linha de comando openrsync incluída no Sequoia
- Os recursos suportados pelo openrsync no macOS Sequoia podem ser verificados na página de manual do openrsync
Como verificar no macOS 15.4
- A partir do macOS 15.4, a ferramenta openrsync está vinculada a
/usr/bin/rsync
- Usuários podem executar o openrsync da mesma forma que executavam a ferramenta de linha de comando rsync anteriormente
- As informações de versão do openrsync são verificadas com o seguinte comando
/usr/bin/rsync --version
- A saída é semelhante à seguinte
username@computername ~ % /usr/bin/rsync --version
openrsync: protocol version 29
rsync version 2.6.9 compatible
username@computername ~ %
- A saída mostra protocol version 29 e rsync version 2.6.9 compatible
1 comentários
Opiniões do Hacker News
A documentação é tão pobre que não inspira confiança de que o openrsync possa substituir o rsync
Um programa de cópia de arquivos deveria ser capaz de fazer uma cópia completa, sem perder nem um bit dos dados e metadados do original; se não conseguir, considero inutilizável
Muitas ferramentas de cópia/arquivamento em sistemas Unix-like não fazem uma cópia completa com as opções padrão, e algumas não conseguem fazer isso com nenhuma opção
Também deixei de usar o scp porque, pelo menos até alguns anos atrás, era difícil fazer uma cópia completa quando o sistema operacional ou o sistema de arquivos era diferente, e passei a usar apenas rsync sobre ssh
O rsync é uma das raras ferramentas que, com as opções adequadas, preserva atributos estendidos, ACLs e timestamps de alta precisão mesmo entre sistemas operacionais/sistemas de arquivos diferentes, como entre FreeBSD UFS e Linux XFS
Como a documentação do openrsync não garante esse tipo de cópia completa, por enquanto presumo que ele não consiga fazê-la e o considero inútil
No lado de arquivamento, no Linux, o bsdtar consegue armazenar uma cópia de arquivos quase completa ao usar o formato pax, enquanto os formatos antigos tar/cpio não conseguem conter metadados modernos
No dia a dia, deixo o rsync com alias para
/usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY"O
cpdo coreutils também consegue fazer uma cópia completa com as opções corretas de CLI e de compilação, mas algumas distribuições o compilam sem suporte a atributos estendidos, fazendo apenas uma cópia parcial sem aviso nem erroNós restauramos tudo com muito cuidado, mas às vezes parece que só nós nos importamos com isso
Em princípio, eu pensaria no openrsync como um rsync com menos restrições de licença, não como algo que se comporta de forma diferente
O README do openrsync diz que ele é compatível com o rsync e manda consultar a documentação do rsync
Se atributos estendidos, ACLs e timestamps de alta resolução não forem recursos opcionais no nível do protocolo, para alegar compatibilidade ele não teria de dar suporte a tudo que o rsync moderno suporta?
Caso contrário, fico me perguntando se isso significa que ele aceita o protocolo inteiro, mas simplesmente descarta coisas como ACLs
Ainda assim, o site oficial diz “We are still working on it... so please wait.”
Quem se importar pode simplesmente instalar o rsync
--xattrs,--aclse--hard-links, usados no alias, estão todos ausentes[0]https://github.com/kristapsdz/openrsync/blob/a257c0f495af2b5...
Como usuário relativamente novo de Linux, a gestão de versões dos utilitários de sistema incluídos parece bem bagunçada
Um exemplo típico é o
unzip: ounzipincluído em servidores Debian e em servidores Ubuntu antigos não conseguia lidar com ZIPs criptografados com AES-256, mas, pelo Stack Overflow, parece que algumas distribuições o atualizaram para dar suporte a issoO problema é que é difícil encontrar facilmente um
unzipatualizado; todos afirmam ser a “version 6.00”, mas se comportam de formas diferentes, e, mesmo encontrando um, não dá para saber se é seguro substituir o pacote do sistemaNo fim, mesmo que alguém tenha adicionado um bom recurso a um utilitário amplamente usado, você ainda não consegue usá-lo; por ser um utilitário essencial do sistema, parece até mais difícil de atualizar do que uma ferramenta de terceiros
Windows e macOS podem ser parecidos ou até piores nesse aspecto de utilitários de sistema, mas eu achava que o Linux lidaria melhor com isso
unzipQuase não me lembro de ter usado
unzipno Linux para lidar com ZIPs ou arquivos compactados em geralPela filosofia Unix, também é natural o fluxo de encadear por pipes ferramentas simples que fazem bem uma coisa só: juntar com tar, compactar com gzip e criptografar com pgp
Quanto à versão, não sei ao certo por que Debian e Ubuntu dizem ambos ser 6.00, mas isso não é comum
Em máquinas pessoais, uma distribuição rolling release como Arch ou Manjaro acompanha as versões upstream de forma mais constante, mas isso aumenta o custo de manutenção e a expectativa de você gerenciar tudo diretamente
Algo mais incômodo na gestão de versões no Linux/open source é que bibliotecas adiam demais a declaração de v1.00
Mesmo já estando amplamente enraizadas no ecossistema, estáveis e praticamente completas em recursos, elas ficam anos em v0.2 ou v0.68, confundindo iniciantes
O Debian tem ciclos de lançamento longos, mas é muito estável, e no stable tudo funciona bem em conjunto
O Ubuntu é basicamente como pegar o Debian e acrescentar “e se lançássemos com mais frequência?”
Se você quer ferramentas mais recentes, precisa aceitar opções possivelmente menos estáveis, como Nix ou Arch, e nenhuma das duas é exatamente amigável
Se quer estabilidade e ferramentas recentes, Gentoo é uma opção, mas dá ainda mais trabalho que Arch
Se quer estabilidade e simplicidade, pode sacrificar espaço em disco e usar abordagens como Docker/podman, flatpak, appcontainers ou snap
Windows e Mac têm o mesmo problema, e o Windows historicamente resolveu isso levando junto bibliotecas antigas e fazendo link dinâmico conforme o app em execução
unzipé um caso especialO desenvolvimento upstream praticamente parou, e o último lançamento foi a versão 6.0, de 2009
Depois disso, vários problemas foram encontrados e recursos passaram a faltar, então cada distribuição empilhou um monte de patches sobre aquele lançamento; como resultado, surgiram executáveis muito diferentes com o mesmo número de versão
[0]: https://infozip.sourceforge.net/UnZip.html
[1]: Pela receita de build do Arch, dá para ver a quantidade de patches aplicados: https://gitlab.archlinux.org/archlinux/packaging/packages/un...
Alguma interoperabilidade é bom, mas ter várias opções também é uma vantagem
A maioria dos repositórios de distribuições tem bsdtar, então vale experimentar como alternativa; dependendo da distribuição, o nome do pacote pode ser libarchive
Com
bsdtar xf path/to/file, dá para extrair quase qualquer formato, e ele também suporta AES em ZIPNo macOS ele vem incluído por padrão, e provavelmente também está incluído no Windows
Para cada coisa que faço, crio um repositório git e um
flake.nix, e faço o direnv ativar o ambiente declarado no flake ao entrar naquele diretórioSe escrevo um script que usa
grep, coloco o script no repositório e também adicionopkgs.gnugrepaoflake.nixAssim, em vez da versão do sistema, é usada a versão declarada; ao migrar do macOS para Linux ou WSL, o mesmo grep, na mesma versão, será chamado
Muita gente diz que o Nix não é amigável para iniciantes, então tenho cautela em recomendá-lo diretamente, mas o ponto central é declarar as dependências de alguma forma e usar apenas as dependências declaradas
Docker também serve, e ecossistemas de linguagens como Python/Node.js/Go/Rust também oferecem formas de agrupar e chamar dependências
Assim, atualizações de dependências ficam registradas em commits, e, se algo quebrar, dá para voltar ao commit anterior
Esse repositório não precisa necessariamente ser um projeto de software; pode ser apenas um “conjunto de ferramentas necessárias para fazer XYZ”
É um pouco incômodo que o openrsync não dê suporte a alguns recursos do rsync
Ainda assim, é bom que agora existam várias implementações independentes do rsync
porque isso significa que o rsync está sendo tratado não como um simples software, mas como um verdadeiro protocolo
Se ele se aproximar de um protocolo, acho que podem surgir pontos de API de diff binário baseados no algoritmo do rsync
Um fato interessante: o Dropbox usava internamente diffs binários do rsync para enviar rapidamente pequenas alterações em arquivos grandes
Imagino que ainda seja assim, mas a API pública não oferece esse endpoint, então mesmo que haja só uma pequena alteração em um arquivo grande é preciso reenviar o arquivo inteiro
Em ambientes corporativos em que SSH+rsync é bloqueado, mas a criação de serviços gRPC é permitida, isso é bem útil
Como o rsync tem muitos recursos, isso inevitavelmente leva bastante tempo
No patch da linha principal do rsync, foi adicionado suporte a atributos estendidos para dar suporte a metadados do macOS
O “Carbon Copy Cloner”, da Bombich, é um app com GUI que encapsula isso
https://support.bombich.com/hc/en-us/articles/20686446501143...
Conheci Mike Bombich por meio de posts em fóruns de administradores de sistemas do macOS Server, e também há material relacionado
https://web.archive.org/web/20140707182312/http://static.afp...
Nathaniel Gray criou o Backup Bouncer, que verifica a fidelidade de backups, incluindo múltiplos streams, atributos estendidos, ACLs etc.
https://github.com/n8gray/Backup-Bouncer
Também existe o RsyncX, um app em SwiftUI que encapsula o rsync
https://github.com/rsyncOSX/RsyncOSX
Na época em que se rodava software “Classic” do macOS sobre o novo sistema UNIX, essas coisas eram consideradas realmente importantes
https://web.archive.org/web/20161022012615/http://blog.plast...
IFileOperation (Windows) e FileManager (macOS) realizam a cópia mais eficiente que o sistema de arquivos subjacente oferece
Em SMB e ReFS, a verificação por CRC é praticamente uma opção de checkbox e, em compartilhamentos SMB modernos no Windows Server moderno, a etapa de correspondência de conteúdo do rsync é trabalho duplicado
Entre Windows, o IFileOperation pode ter throughput 1,5 a 8 vezes maior que o rsync, com menor uso de CPU, e também pode ser 1,2 a 3 vezes mais rápido que uma cópia de arquivos comum em Go
Se você olhar apenas para Linux, sem se preocupar com sistemas operacionais que realmente usam metadados complexos de sistema de arquivos, o openrsync ou programas mais simples são suficientes
Fico curioso se existe algum material que explique bem por que a Apple tem tanto medo da GPLv3
Parece que, se o executável for compilado estaticamente, isso não deveria ser um problema
Na época, a TiVo fazia isso, por isso o fenômeno ficou conhecido como tivoização
No iOS, o motivo para não usar GPLv3 é claro: isso violaria as condições
No macOS, seria possível incluir código GPLv3, mas a Apple compartilha muito código entre iOS/macOS/watchOS/tvOS/visionOS, então não faz muito sentido basear apenas um sistema operacional em GPLv3 e não usar nos demais
É mais simples simplesmente não usar nada disso
Além disso, mesmo que no futuro a Apple restrinja ainda mais a execução de código de usuário no macOS, ela não precisará se preocupar em arrancar código GPLv3 naquele momento
Coisas que eu achava totalmente seguras não eram vistas pelos advogados de forma tão categórica
Não sei quais são os motivos da Apple, mas advogados corporativos de outras empresas davam a orientação de escolher licenças não GPL sempre que possível
Olhando o histórico de jurisprudência envolvendo a GPLv2, parece haver pouco ganho para o esforço envolvido
Do ponto de vista da Apple, se ela simplesmente substitui a parte que parece um “problema”, consegue evitar toda a categoria de problemas
Os detalhes técnicos específicos podem até ser interessantes, mas, a meu ver, não são o ponto central
É melhor não confiar nas explicações de outras pessoas sobre as intenções da Apple
Ao escrever diretamente em Go a implementação https://github.com/gokrazy/rsync, dei uma olhada no openrsync, e o código era bom
Só é uma pena que o openrsync não seja 100% compatível com o rsync
Descobri que a Apple tinha começado a migrar para o openrsync quando meus testes quebraram no macOS 15
Dizem que o openrsync foi escrito como parte do projeto rpki-client(1), um validador de RPKI para OpenBSD, e que NetNod, IIS.SE, SUNET e 6connect financiaram o trabalho; fico curioso para saber por que essas organizações financiaram esse desenvolvimento
https://github.com/kristapsdz/openrsync?tab=readme-ov-file#p...
https://news.ycombinator.com/item?id=43605846
Empresas financiam coisas úteis ou necessárias
Algumas das empresas da lista podem usar BSD e talvez quisessem ou precisassem de uma implementação do rsync que não fosse GPLv3
Ou talvez simplesmente tivessem interesse em apoiar projetos e desenvolvimento open source
Por um tempo, até o Sequoia 15.3, era possível usar tanto rsync_samba quanto rsync_openrsync por meio de
/var/select/rsyncou da variável de ambienteCHOSEN_RSYNCO ponto especialmente irritante do openrsync é que ele afirmava dar suporte ao elemento mágico de caminho
/./para--relativeEnviei um relatório de bug à Apple sobre esse problema cerca de um mês atrás
A partir do Sequoia 15.4, o rsync_samba desapareceu, e deixei o rsync instalado pelo Homebrew
Passei por esse problema recentemente: quando se cria um
.ipade iOS pela linha de comando comxcodebuild, parece que ele chama o rsync internamente para copiar arquivos entre diretórios locaisSó que o rsync do Homebrew estava antes no
$PATH, então foi ele que acabou sendo executado, e oxcodebuildpassou o argumento exclusivo do openrsync--extended-attributesO rsync do Homebrew não entendeu esse argumento, falhou e encerrou
Ainda fico contente que a Apple não esteja tentando transformar o osx em algo como o iOS removendo gradualmente o lado POSIX, e sim continue melhorando e adotando isso