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

As principais diferenças entre uma cópia virtual do sistema de arquivos e um link simbólico são que as getcwd(3)funções funcionam corretamente na cópia virtual,

getcwdO comportamento do 's com diretórios com links simbólicos é uma pegadinha bastante conhecida, documentada em Advanced Unix Programming , por exemplo (consulte esta pergunta do SO para obter uma citação): chdire getcwdnão são simétricos quando os links simbólicos estão envolvidos. Pode-se esperar que alterar 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 - getcwdretorna o caminho obtido após a desreferência de todos os links simbólicos. Isso pode ter consequências inesperadas ao alterar diretórios para um diretório pai, quando o caminho que contém o(s) link(s) simbólico(s) e o caminho desreferenciado têm diferentes números de componentes.

e que outros sistemas de arquivos podem ser montados na cópia virtual sem afetar o original.

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

Um número de dispositivo diferente para a cópia virtual é retornado por stat(2), mas em outros aspectos é indistinguível do original.

Isso significa que a execução statda cópia, ou qualquer arquivo abaixo dela, 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)retornaria a mesma informação.

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

• depois chdir("/tmp/a"), getcwd()retorna /some/dir.
• depois chdir("/tmp/b"), getcwd()retorna /tmp/b.

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

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

A manipulação de links simbólicos pode quebrar as expectativas de algumas pessoas (como essa getcwd()aqui), mas as montagens nullfs (ou o sistema de arquivos fusível bindfs no Linux ou alguns sistemas de arquivos union) podem quebrar as expectativas de outras pessoas, como o fato [ /tmp/b/x -ef /some/dir/x ]retornaria falso mesmo que sejam o mesmo arquivo abaixo, ou que fuser /tmp/b/xnão poderia retornar nada mesmo quando houver processos que o tenham aberto pelo /some/dir/xcaminho.

As montagens vinculadas do Linux (que não fazem os arquivos parecerem diferentes) podem quebrar as expectativas de outras pessoas, como find -xdev/ du -xatravessar o ponto de montagem, dois links para o mesmo arquivo com uma contagem de links de 1 (também permite loops para ser criado no sistema de arquivos; o nullfs do FreeBSD protege contra isso).

Links físicos (a mais antiga daquelas tecnologias que fazem os arquivos aparecerem em caminhos diferentes) também podem quebrar as expectativas de alguns usuários (como 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 que o outro aqui.