Significado da declaração de que 'funções getcwd funcionam corretamente' na página man do FreeBSD para mount_nullfs?

Question

No FreeBSD, man mount_nullfs afirma que:

The primary differences between a virtual copy of the file system and a symbolic link are that the getcwd(3) functions work correctly in the virtual copy, and that other file systems may be mounted on the virtual copy without affecting the original. A different device number for the virtual copy is returned by stat(2), but in other respects it is indistinguishable from the original.

Qual é o significado / implicação total deste parágrafo?

    

Answer 1

The primary differences between a virtual copy of the file system and a symbolic link are that the getcwd(3) functions work correctly in the virtual copy,

O comportamento de

getcwd com diretórios ligados por links simbólicos é uma pegadinha razoavelmente bem conhecida, documentada em Programação Unix Avançada por exemplo (veja esta pergunta SO para uma cotação): chdir e getcwd não são simétricos quando links simbólicos estão envolvidos. Pode-se esperar que a mudança de diretórios, usando chdir , para um determinado diretório e, em seguida, recuperar o diretório atual, usando getcwd , retornaria o mesmo valor; mas esse não é o caso quando um processo muda de diretório usando um caminho contendo um link simbólico - getcwd retorna o caminho obtido após a desconsideração de todos os links simbólicos. Isso pode ter conseqüências inesperadas ao alterar diretórios para um diretório pai, quando o caminho que contém o link simbólico e o caminho de referência tiverem diferentes números de componentes.

and that other file systems may be mounted on the virtual copy without affecting the original.

Continuando o exemplo de Stéphane, você pode montar outro sistema de arquivos em um subdiretório de /tmp/b sem afetar /some/dir , enquanto a montagem de um sistema de arquivos em um subdiretório de /tmp/a fará com que ele apareça em /some/dir também.

A different device number for the virtual copy is returned by stat(2), but in other respects it is indistinguishable from the original.

Isso significa que a exibição de stat na cópia ou em qualquer outro arquivo retornará um número de dispositivo diferente do original, mas essa é a única diferença; Além disso, stat("/tmp/b/c", &buf) e stat("/some/dir/c", &buf) retornariam as mesmas informações.

    

Answer 2

Eu acho que eles querem dizer que se /tmp/a é um link simbólico para /some/dir e /tmp/b é uma montagem nula de /some/dir ,

• após chdir("/tmp/a") , getcwd() retorna /some/dir .
• após chdir("/tmp/b") , getcwd() retorna /tmp/b .

Não é tanto que o primeiro esteja incorreto . É só que os links simbólicos e os nulos têm duas semânticas diferentes.

Um link simbólico é um ponteiro para outro arquivo que a maioria das chamadas de sistema (incluindo chdir() ) segue, enquanto uma montagem nullfs torna uma árvore de diretório inteira disponível em um caminho diferente (e contrário ao recurso ou diretório de montagem de ligação similar do Linux) hard links em alguns outros sistemas, os arquivos aparecem como arquivos diferentes).

O manuseio do symlink pode quebrar algumas expectativas de pessoas (como getcwd() aqui), mas as montagens nullfs (ou o sistema de arquivos fuse do bindfs no Linux ou alguns sistemas de arquivos union) podem quebrar expectativas de outras pessoas como o fato [ /tmp/b/x -ef /some/dir/x ] retornaria false mesmo que sejam o mesmo arquivo abaixo ou que fuser /tmp/b/x não retorne nada mesmo quando houver processos que o abriram por meio do caminho /some/dir/x .

As montagens de ligação do Linux (que não fazem os arquivos parecerem diferentes) podem quebrar algumas expectativas de outras pessoas, como find -xdev / du -x atravessando o ponto de montagem, dois links para o mesmo arquivo com um link count de 1 (também permite que loops sejam criados no sistema de arquivos; o nullfs do FreeBSD protege contra isso).

Hard links (a mais antiga dessas tecnologias que fazem com que os arquivos apareçam em caminhos diferentes) também podem quebrar algumas expectativas dos usuários (assim quando você desvincula um arquivo de um diretório, espera que ele não esteja mais disponível).

Então, eu não diria que um é mais correto do que o outro aqui.