modifica a data do symlink em bindfs

3

Tenho a sensação de que não posso modificar a data de links simbólicos em bindfs. Veja a seguinte transcrição do que eu tentei.

Em EXT4:

nailor@needle:~$ mkdir /tmp/ex
nailor@needle:~$ cd /tmp/ex
nailor@needle:/tmp/ex$ touch realfile  
nailor@needle:/tmp/ex$ ln -s realfile linkfile
nailor@needle:/tmp/ex$ stat realfile linkfile
  File: 'realfile'
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: 801h/2049d  Inode: 22678377    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  nailor)   Gid: ( 1000/  nailor)
Access: 2013-09-09 00:46:15.356004837 +0200
Modify: 2013-09-09 00:46:15.356004837 +0200
Change: 2013-09-09 00:46:15.356004837 +0200
 Birth: -
  File: 'linkfile' -> 'realfile'
  Size: 8           Blocks: 0          IO Block: 4096   symbolic link
Device: 801h/2049d  Inode: 22678380    Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/  nailor)   Gid: ( 1000/  nailor)
Access: 2013-09-09 00:46:34.299766676 +0200
Modify: 2013-09-09 00:46:27.227855586 +0200
Change: 2013-09-09 00:46:27.227855586 +0200
 Birth: -
nailor@needle:/tmp/ex$ touch -h realfile linkfile
nailor@needle:/tmp/ex$ stat realfile linkfile    
  File: 'realfile'
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: 801h/2049d  Inode: 22678377    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  nailor)   Gid: ( 1000/  nailor)
Access: 2013-09-09 00:46:46.931607877 +0200
Modify: 2013-09-09 00:46:46.931607877 +0200
Change: 2013-09-09 00:46:46.931607877 +0200
 Birth: -
  File: 'linkfile' -> 'realfile'
  Size: 8           Blocks: 0          IO Block: 4096   symbolic link
Device: 801h/2049d  Inode: 22678380    Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/  nailor)   Gid: ( 1000/  nailor)
Access: 2013-09-09 00:46:49.899570563 +0200
Modify: 2013-09-09 00:46:46.931607877 +0200
Change: 2013-09-09 00:46:46.931607877 +0200
 Birth: -

Em bindfs:

nailor@needle:/tmp/ex$ mkdir sub      
nailor@needle:/tmp/ex$ bindfs -n . sub
nailor@needle:/tmp/ex$ cd sub
nailor@needle:/tmp/ex/sub$ touch -h realfile linkfile 
nailor@needle:/tmp/ex/sub$ stat realfile linkfile 
  File: 'realfile'
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: 17h/23d Inode: 2           Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  nailor)   Gid: ( 1000/  nailor)
Access: 2013-09-09 00:47:34.000000000 +0200
Modify: 2013-09-09 00:47:34.000000000 +0200
Change: 2013-09-09 00:47:34.755006803 +0200
 Birth: -
  File: 'linkfile' -> 'realfile'
  Size: 8           Blocks: 0          IO Block: 4096   symbolic link
Device: 17h/23d Inode: 3           Links: 1
Access: (0777/lrwxrwxrwx)  Uid: ( 1000/  nailor)   Gid: ( 1000/  nailor)
Access: 2013-09-09 00:46:49.899570563 +0200
Modify: 2013-09-09 00:46:46.931607877 +0200
Change: 2013-09-09 00:46:46.931607877 +0200
 Birth: -

Como você pode ver, os tempos para o symlink não foram alterados em bindfs. Este é um problema com, e. rsync, porque desta forma eu recebo:

rsync: failed to set times on "link1": No such file or directory (2)
rsync: failed to set times on "link2": No such file or directory (2)
...

Descobri que este é um problema conhecido com o sshfs ( link ), mas encontrado nada mencionando bindfs. Agora eu estou querendo saber se existe alguma menção e / ou explicação para a funcionalidade ausente e / ou uma resposta se isso afetar o fusível em geral ...

    
por mnagel 09.09.2013 / 00:57

2 respostas

5

Sistemas de arquivos nos quais você não pode alterar a data de um symlink são comuns. Isso por si só não é um bug de bindfs ou sshfs.

O Rsync foi projetado para lidar com isso. Ele ignora falhas para alterar o tempo e outros metadados de links simbólicos se o sistema de arquivos subjacente não suportar.

No Linux, o rsync chama utimensat com o sinal AT_SYMLINK_NOFOLLOW para alterar os tempos do simbólico ligação. Tanto quanto eu posso dizer, o problema é que a API do FUSE não tem sinalizador correspondente para utimens (ou utime ), portanto, a implementação do sistema de arquivos só vê uma solicitação para alterar a hora e nenhuma indicação de seguir ou não o link simbólico. Na falta de qualquer indicação específica, tanto o bindfs quanto o sshfs agem de maneira compatível com versões anteriores: eles modificam o alvo do link simbólico. Para um link simbólico quebrado, isso resulta em um erro ENOENT.

À primeira vista, pensei que isso fosse um bug no FUSE: como o FUSE não consegue passar o sinalizador AT_SYMLINK_NOFOLLOW , ele deve retornar um erro (EINVAL ou ENOTSUP). No entanto, a partir de uma leitura superficial do código VFS do Linux , parece que o O código específico do sistema de arquivos é chamado no link simbólico ou no seu destino e, portanto, nunca deve seguir nenhum link simbólico. Isso faz todo o sentido: o alvo do link simbólico pode estar em um sistema de arquivos diferente.

Então eu acho que isso é um bug em bindfs e sshfs (e provavelmente em muitos outros sistemas de arquivos FUSE): se for instruído a alterar os metadados de um link simbólico, eles devem afetar apenas aquele link simbólico ou retornar um erro se o solicitado a mudança não é possível.

    
por 09.09.2013 / 01:51
2

Este bug agora é corrigido em bindfs versão 1.12.3.

A resposta de Gilles explica o erro de maneira soberba.

    
por 23.09.2013 / 23:20

Tags