O comando ln pode criar links físicos no compartilhamento do Windows montado, mas cp -al falha. Esse comportamento é esperado? Estou tentando economizar espaço em disco criando uma cópia nos backups de estilo de gravação usando cowdancer , rsync e cp -al .
backupuser@lan0:/mnt/backup/share$ mkdir a
backupuser@lan0:/mnt/backup/share$ touch a/b
backupuser@lan0:/mnt/backup/share$ cp -al a x
cp: cannot create hard link 'x/b' to 'a/b': No such file or directory
backupuser@lan0:/mnt/backup/share$ mkdir x
mkdir: cannot create directory 'x': File exists
backupuser@lan0:/mnt/backup/share$ ln a/b x/b
backupuser@lan0:/mnt/backup/share$ ls -l x
total 0
-rwxr-xr-x 0 backupuser backupuser 0 Dec 23 17:33 b
Atualização: ln está realmente criando uma cópia e não um link real
Você está executando o SAMBA como servidor? Em seguida, procure por "extensões unix" em "smb.conf" e ative-as.
Com "extensões unix" ativadas, o SAMBA suporta links de hardware, informações de propriedade do Unix e modo para arquivos e diretórios (ou permissões).
No entanto, essa configuração é uma configuração global. Portanto, a ativação de extensões unix afeta todos os compartilhamentos (que podem ou não ser o que você deseja).
Eu recentemente testei isso usando o Windows 10 Pro como servidor. Meu sistema Linux está executando o CentOS 7, que a partir de hoje vem com o Samba 4.4.4. Hardlink funciona bem como em um sistema de arquivos local.
Testes:
/mnt/f/tmp# mkdir a
/mnt/f/tmp# touch a/b
/mnt/f/tmp# cp -al a x
/mnt/f/tmp# stat a/b
File: ‘a/b’
Size: 0 Blocks: 0 IO Block: 16384 regular empty file
Device: 28h/40d Inode: 1688849861497214 Links: 2
Access: (0755/-rwxr-xr-x) Uid: ( 1000/ yanli) Gid: ( 1000/ yanli)
Context: system_u:object_r:cifs_t:s0
Access: 2017-05-17 14:31:43.564755100 -0700
Modify: 2017-05-17 14:31:43.564755100 -0700
Change: 2017-05-17 14:31:46.571727600 -0700
Birth: -
/mnt/f/tmp# stat x/b
File: ‘x/b’
Size: 0 Blocks: 0 IO Block: 16384 regular empty file
Device: 28h/40d Inode: 1688849861497214 Links: 2
Access: (0755/-rwxr-xr-x) Uid: ( 1000/ yanli) Gid: ( 1000/ yanli)
Context: system_u:object_r:cifs_t:s0
Access: 2017-05-17 14:31:43.564755100 -0700
Modify: 2017-05-17 14:31:43.564755100 -0700
Change: 2017-05-17 14:31:46.571727600 -0700
Birth: -
/mnt/f/tmp# echo something >a/b
/mnt/f/tmp# cat x/b
something
/mnt/f/tmp# mount | grep /mnt/f
//192.168.1.7/f on /mnt/f type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,cache=strict,username=redacted,domain=REDACTED,uid=1000,forceuid,gid=1000,forcegid,addr=192.168.1.7,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=61440,wsize=65536,echo_interval=60,actimeo=1,user)
Como você pode ver, o arquivo a/b e x/b tem o mesmo número de Inode, indicando que são hardlinks para o mesmo Inode. Alterar o conteúdo de um arquivo também afeta o outro arquivo.
ln também funciona corretamente.
Nenhuma opção especial foi usada para montar o CIFS; cada opção era padrão. Eu não fiz nada de especial no lado do Windows também. É apenas uma instalação padrão do Windows 10 Pro e uma pasta compartilhada simples.
O que eu ainda não sei é quando esse recurso foi adicionado ao cliente CIFS / Samba / Windows. OP apenas disse "Windows share", então não está claro qual versão do Windows / Samba ele / ela estava rodando. Espero que minha resposta possa ajudar aqueles que têm problemas com a criação de hardlinks no compartilhamento montado em CIFS apoiado por um servidor Windows; você pode resolver o problema atualizando para o Windows 10 Pro e pelo menos o Samba 4.4.4 (o CentOS não é conhecido por enviar o código mais recente e mais recente).