Eu entendo porque links rígidos em diretórios são perigosos (loops, problemas para o rmdir por causa do link diretório-pai) e li as outras questões sobre esse tópico. Então presumi que hard links em diretórios, além de . e .. , não são usados. E ainda vejo o seguinte no CentOS 5 & 6:
# ls -id /etc/init.d/
459259 /etc/init.d/
# ls -id /etc/rc.d/init.d/
459259 /etc/rc.d/init.d/
# ls -id /etc/init.d/../
458798 /etc/init.d/../
# ls -id /etc/rc.d/
458798 /etc/rc.d/
# ls -id /etc/
425985 /etc/
Em outras palavras, 2 caminhos diferentes para diretórios apontando para o mesmo inode e o pai de /etc/init.d/ apontando para /etc/rc.d/ em vez de /etc/ . Este é realmente um caso de diretórios com hard-link? se não, o que é? Se sim, por que a Red Hat faz isso?
Edit: me desculpe por fazer uma pergunta estúpida, eu deveria ter visto que é um link simbólico. Não há café suficiente hoje, parece.
Isso é soft-link, não hard link. Links simbólicos apontam para outros arquivos. Abrir um link simbólico abrirá o arquivo para o qual o link aponta. Remover um link simbólico com rm removerá o próprio link simbólico, mas não o arquivo real.
Isso é indicado pela letra l no início das permissões
lrwxrwxrwx. 1 root root 11 Aug 10 2016 init.d -> rc.d/init.d
Além disso, todos os rc0.d para rc6.d são links simbólicos para rc.d / rc0.d
No RHEL, Fedora e CentOS, /etc/init.d é um symlink para /etc/rc.d/init.d . Não há link físico envolvido.
Mesmo que a Red Hat quisesse, não seria possível nos sistemas de arquivos usados.
Este post é um pouco antigo, mas não sinto que o comportamento que o OP está vendo tenha sido explicado. Como outros afirmaram, /etc/init.d é um link simbólico para /etc/rc.d/init.d . A parte ausente é a razão pela qual ambos os caminhos usados acima retornam o mesmo inode, que é devido ao uso da barra de avanço. Quando um caminho termina em uma barra, ele informa ao kernel e outras ferramentas que um diretório é destinado. Ele pode proteger um comando mv / cp de renomear um arquivo quando o destino pretendido deveria ser um diretório que realmente não existe. Ele também faz com que a chamada de sistema lstat (2) usada por ls desrefere o link simbólico e, em vez disso, retorna o diretório para o qual ele aponta (ou lança um erro se não apontar para um diretório existente). Experimente este exemplo para ver a diferença:
$ ls -id .
927578 .
$ ls -id ./parent
927641 ./parent
$ ls -id ./parent/
927641 ./parent/
$ ls -id ./parent/child
927643 ./parent/child
$ ls -id ./parent/child/
927643 ./parent/child/
$ ls -id ./child
927645 ./child
$ ls -id ./child/
927643 ./child/
$ ls -idL ./child
927643 ./child
$ ls -id ./child/..
927641 ./child/..
$ ls -id ./child/../..
927578 ./child/../..
Você pode ver que a presença da barra final é importante apenas para o caso de link simbólico, mas oculta o inode do link. Além disso, a opção -L para ls faz algo semelhante, embora para qualquer tipo de arquivo.