OK, então, com base no comentário de Daniel B acima, eu testei três métodos.
Eu testei estes em uma unidade local para transferência de unidade local em que find . -name '*somestring*'
encontrou 495 arquivos, com média de 5.8MB e totalizando 2.82GB. O primeiro resultado de tempo para cada método é com o diretório de destino vazio para que todos os 495 arquivos sejam copiados. O segundo resultado de sincronismo é com o destino já correspondendo à fonte, para que nenhum arquivo seja copiado.
1 - Usando exec no comando find:
time find . -name '*somestring*' -type f -exec cp -v --update -i {} -t '../dst/' \;
real 2m2.037s
real 0m35.043s
2 - Lista de tubulação de arquivos diretamente para o cp:
time find . -name '*somestring*' -type f -print0 | xargs -0 cp -v --update -t '../dst/'
real 1m42.354s
real 0m3.463s
3 - Usando rsync
time rsync -vh --update *somestring* '../dst/'
real 1m53.605s
real 0m2.300s
Então, nessa situação, rsync
basicamente empatou com cp
. No entanto, quando voltei ao meu aplicativo real de cópia de um local de rede para outro, descobri que rsync
assumiu a liderança. No meu cenário real, o piping find
to cp
demorou cerca de 15 segundos quando o diretório dst já correspondia a src, enquanto rsync
demorou cerca de 7 segundos.
Então rsync é!