Introdução

A cena retrata Sísifo, condenado pelos deuses a empurrar eternamente uma pedra morro acima, apenas para vê-la rolar de volta antes do topo. Copiar e colar diretórios/pastas é uma das práticas mais comuns — e mais perigosas — quando lidamos com dados importantes.

Ela “funciona” na maior parte do tempo, mas falha exatamente quando importa falhar de forma visível.

Copiar e colar não responde perguntas fundamentais:

  • O que mudou?
  • O que foi sobrescrito?
  • O que ficou para trás?
  • Posso provar que dois diretórios são iguais?
  • O que falhou silenciosamente?

Na ausência dessas respostas, criamos uma ilusão de segurança.

Este artigo parte de uma premissa simples: filesystem é estado, não apenas um conjunto de arquivos. E mostra por que uma abordagem baseada em diff explícito, auditoria e sincronização consciente resolve problemas que o sistema operacional — e a maioria das ferramentas — ignora.

O problema real: estados divergentes

Considere dois diretórios:

  • A: ambiente de trabalho
  • B: backup, NAS, servidor ou ambiente de staging

Eles não são apenas “pastas”. Eles representam estados distintos no tempo.

Entre A e B existem diferenças acumuladas:

  • arquivos criados
  • arquivos modificados
  • arquivos removidos
  • falhas de leitura
  • permissões diferentes

Copiar e colar tenta substituir um estado pelo outro sem entender essas diferenças.

É uma operação cega.

Engenharia exige o oposto:

entender o diff antes de aplicar qualquer mudança.

Filesystem não é só arquivo

Em ambientes reais, filesystem nunca é homogêneo.

Existem:

  • sockets (ex: mysql.sock)
  • arquivos acessíveis apenas como root
  • symlinks quebrados
  • volumes Docker montados dentro de diretórios
  • arquivos que desaparecem durante o scan
  • permissões inconsistentes
  • nomes válidos em um filesystem e inválidos em outro

Scripts ingênuos assumem que tudo é arquivo regular. Eles quebram.

Ferramentas robustas fazem algo diferente:

  • identificam o tipo da entidade
  • classificam o risco
  • decidem o que ignorar
  • registram o que não pode ser processado

Antes de copiar qualquer coisa, é preciso entender o terreno.

Diff explícito como conceito central

A abordagem correta começa com um princípio simples:

Nunca sincronize sem saber exatamente o que vai mudar.

Em vez de “copiar tudo”, uma abordagem consciente separa o problema em categorias explícitas:

  • diretórios ausentes
  • arquivos novos
  • arquivos modificados
  • arquivos extras no destino

Cada categoria representa um tipo diferente de decisão.

Isso transforma uma operação destrutiva — sobrescrever dados — em um processo auditável, onde:

  • nada acontece por acaso
  • nada é silencioso
  • tudo pode ser explicado depois

O diff deixa de ser um detalhe técnico e passa a ser o objeto central da decisão.

Onde a maioria das ferramentas falha

Muitas ferramentas até implementam sincronização, mas:

  • misturam diff com execução
  • não distinguem erro de ausência
  • escondem falhas de permissão
  • normalizam nomes silenciosamente
  • tratam dry-run como “quase execução”

Isso cria uma falsa sensação de controle.

Na prática, o usuário não sabe:

  • o que foi realmente copiado
  • o que foi ignorado
  • o que falhou
  • se o estado final é confiável

Uma abordagem consciente: fsync-conscious

Foi desse conjunto de problemas que surgiu o fsync-conscious.

Não como uma tentativa de substituir ferramentas consolidadas, mas como uma materialização explícita desse modelo mental.

A ferramenta parte de decisões claras:

  • diff explícito sempre vem antes do sync
  • filesystem é tratado como estado mutável
  • falhas são classificadas, não escondidas
  • dry-run executa toda a lógica, sem efeitos colaterais
  • hash é opcional, não dogma
  • nada é renomeado ou “corrigido” automaticamente

Em vez de perguntar “copiou ou não copiou?”, a ferramenta responde:

o que mudou, por que mudou e o que não pôde ser processado.

O projeto:

Hash não é garantia, é privilégio

Existe um fetiche comum em engenharia:

“Sem hash, não é seguro.”

Na prática, isso ignora o mundo real.

Comparar arquivos por hash exige:

  • permissão de leitura completa
  • estabilidade do arquivo durante a leitura
  • custo computacional relevante
  • mais pontos de falha

Por isso uma ferramenta consciente:

  • usa mtime como default
  • permite hash como modo forte (--hash)
  • tolera falhas de leitura
  • registra arquivos ilegíveis
  • continua operando

Esse comportamento permite uma engenharia pragmática, alinhada com ferramentas de backup profissionais.

Conclusão

Copiar e colar resolve uma ação. Sincronização consciente resolve um processo.

Quando dados importam:

  • visibilidade vence conveniência
  • controle explícito vence automatismo cego
  • auditoria vence confiança implícita

Pensar filesystem como estado muda tudo:

  • muda como você copia
  • muda como você valida
  • muda como você confia

Ferramentas como o fsync-conscious não existem para “facilitar a vida”, mas para tornar o comportamento explícito.

E, em engenharia, isso é o que separa acaso de responsabilidade.