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.