rsync --link-dest não funciona como esperado com links simbólicos

0

Estou usando rsync para fazer backup de alguns dos meus arquivos:

rsync -aEN --delete --link-dest="$CURR/" "$SOURCE/" "$NEW/"

A opção --link-dest funciona bem com a maioria dos arquivos, mas não com links simbólicos.
Quando eu estava escrevendo um script de limpeza para backups antigos, notei que os links simbólicos não modificados não têm link físico, mas sim são copiados.

Agora estou pensando:
Existe uma maneira de tornar rsync links simbólicos não alterados inalterados também?
E se não: é intencional ou um bug no rsync?

Estou usando o rsync versão 3.1.1 no Mac OS 10.11.

Editar:

Parece ser um problema no Mac OS X. Por alguma razão, o HFS + parece não suportar hard-links para links simbólicos.

    
por Sven 17.06.2016 / 16:25

2 respostas

2

O sistema de arquivos no Mac OS X (HFS +) não suporta links físicos para links simbólicos:

$ touch file
$ ls -l file
-rw-r--r-- 1 kk staff 0 Jun 17 18:35 file

$ ln -s file slink
$ ls -l file slink
-rw-r--r-- 1 kk staff 0 Jun 17 18:35 file
lrwxr-xr-x 1 kk staff 4 Jun 17 18:36 slink -> file

O seguinte normalmente criaria um link físico para um link simbólico, e é documentado no manual ln no OS X para fazer isso (EDIT: não, a menos que você tenha o GNU coreutils instalado): / p>

$ ln -P slink hlink
$ ls -l file slink hlink
-rw-r--r-- 1 kk staff 0 Jun 17 18:35 file
lrwxr-xr-x 1 kk staff 4 Jun 17 18:38 hlink -> file
lrwxr-xr-x 1 kk staff 4 Jun 17 18:36 slink -> file

Você pode ver pela contagem de referência (1) que nenhum nome novo foi criado para slink (teria sido 2 para slink e hlink se tivesse funcionado). Além disso, stat nos diz que hlink é um link simbólico com 1 inode link (não 2):

$ stat hlink
  File: 'hlink' -> 'file'
  Size: 4               Blocks: 8          IO Block: 4096   symbolic link
Device: 1000004h/16777220d      Inode: 83828644    Links: 1
Access: (0755/lrwxr-xr-x)  Uid: (  501/      kk)   Gid: (   20/   staff)
Access: 2016-06-17 18:38:18.000000000 +0200
Modify: 2016-06-17 18:38:18.000000000 +0200
Change: 2016-06-17 18:38:18.000000000 +0200
 Birth: 2016-06-17 18:38:18.000000000 +0200

EDIT: Desde que eu fui pego usando o GNU Coreutils, aqui estão os testes novamente com /bin/ln no OS X:

$ touch file
$ /bin/ln -s file slink
$ /bin/ln slink hlink   # there is no option corresponding to GNU's -P
$ ls -l file slink hlink
-rw-r--r--  2 kk  staff  0 Jun 17 18:59 file
-rw-r--r--  2 kk  staff  0 Jun 17 18:59 hlink
lrwxr-xr-x  1 kk  staff  4 Jun 17 18:59 slink -> file

O link físico está apontando para file em vez de slink .

Por exemplo, Linux e OpenBSD (os outros sistemas operacionais que eu uso), é possível fazer isso, o que resulta em

$ ls -l file slink hlink
-rw-rw-r-- 1 kk kk 0 Jun 17 18:35 file
lrwxrwxrwx 2 kk kk 4 Jun 17 18:43 hlink -> file
lrwxrwxrwx 2 kk kk 4 Jun 17 18:43 slink -> file

(observe "2")

    
por 17.06.2016 / 18:42
1

Você não pode criar hardlinks para links simbólicos (isto não é uma "limitação" do OS X). Um hardlink é uma referência a um inode, e um link simbólico não é um inode, mas apenas uma entrada no diretório com alguma informação adicional.

Você pode estar pensando no Windows, que possui recursos semelhantes, que se comportam de maneira diferente.

rsync faz ter uma opção --copy-links que diz para copiar o arquivo para o qual um link simbólico aponta para o destino. Isso seria útil se você estivesse tentando construir uma réplica completa do seu diretório de origem (mas não muito útil se seu objetivo é reduzir o uso do disco).

por 17.06.2016 / 18:41