Quando um link simbólico não é aceitável? [fechadas]

3

Do ponto de vista usuário , para fins de conteúdo do arquivo , link simbólico é o mesmo que o arquivo de destino :

Symbolic links operate transparently for most operations: programs that read or write to files named by a symbolic link will behave as if operating directly on the target file.

No entanto, parece que há situações em que um link simbólico não pode ser usado em vez do arquivo real ( Links simbólicos para arquivos icns são ignorados no Mac OS X .

Existem outros exemplos em unixes mais convencionais?

Especificamente, há situações em que um link simbólico não pode ser usado em vez do arquivo real?

Os aspectos dos quais estou ciente (e, portanto, não estão interessados) são:

  1. Naturalmente, há muitos exemplos de comandos unix que distinguem links simbólicos de seus destinos ( ls , stat , find & c). No entanto, esses comandos lidam com arquivos como objetos do sistema de arquivos, não seus conteúdos .
  2. Outros exemplos incluem medidas de segurança (por exemplo, ftp ou apache recusando-se a get um link para um arquivo fora da árvore).
  3. Ainda mais exemplos podem ser inventados usando "ferramentas elétricas" (por exemplo, emacs pode se comportar de maneira diferente, dependendo se foi chamado em um link simbólico).
  4. Um desenvolvedor pode , é claro, distinguir facilmente entre arquivos e links - e, assim, atrapalhar o usuário. Então, quando eles realmente atrapalharam o usuário (sem um bom motivo, como os ícones do Mac acima)?
por sds 08.12.2014 / 16:12

1 resposta

0

Você não deve mover nenhum diretório pertencente a um pacote do Solaris para um diretório diferente e, em seguida, usar um link simbólico para corrigir o caminho.

Embora funcione inicialmente, assim que você instalar um patch ou um novo pacote que compartilhe alguma parte do caminho anterior do pakage, o link simbólico será removido e substituído por um diretório simples pelos comandos de gerenciamento de pacotes do Solaris.

    
por 08.12.2014 / 17:51

Tags