Por que links físicos não são permitidos para diretórios?


129

Estou usando o Ubuntu 12.04. Quando tento criar um link físico para qualquer diretório, ele falha. Eu posso criar links físicos para arquivos dentro dos limites do sistema de arquivos. Eu sei o motivo pelo qual não podemos criar links físicos para arquivos além do sistema de arquivos.

Eu tentei estes comandos:

$ ln /Some/Direcoty /home/nischay/Hard-Directory
hard link not allowed for directory
$ sudo ln /Some/Direcoty /home/nischay/Hard-Directory
[sudo] password for nischay: 
hard link not allowed for directory

Eu só quero saber a razão por trás disso. É o mesmo para todas as distribuições GNU / Linux e tipos de Unix (BSD, Solaris, HP-UX, IBM AIX) ou apenas no Ubuntu ou Linux?



2
Tente ln -F <src> <dst>e pode funcionar. Certamente, costumava trabalhar para o superusuário em versões mais antigas do Unix. Alguém se lembra se isso era UCB ou System V? Sim, coisas ruins podem acontecer, mas geralmente não. Pelo que me lembro, rmdirsabia não continuar excluindo um link físico passado. No entanto, os usuários podem ficar confusos e excluir as coisas por erro.
Steve jarros

@StevePitchers Como rmdirlidar com links físicos de uma maneira especial? Um link físico é apenas um link normal - mas é um link adicional. Não é fácil descobrir se existem links extras incomuns sem gravações extras.
Volker Siegel

1
Cada nó armazena o número de links físicos que apontam para ele: o conteúdo é liberado apenas quando não houver links restantes. Então, rmdirpodemos dizer se o diretório possui links de outros lugares. A remoção recursiva rm -r, deve ser codificada com cuidado, para garantir que funcione corretamente, mesmo que ocorram erros como "permissão negada". BTW, UCB = BSD, doh!
Steve jarros

2
Eu fiz ln -Fem diretórios e fazê-lo funcionar. Mas você não ousa excluir o diretório posteriormente por medo de corromper o sistema de arquivos.
Edward Falk

Respostas:


159

Os hardlinks de diretório quebram o sistema de arquivos de várias maneiras

Eles permitem criar loops

Um link físico para um diretório pode ser vinculado a um pai, criando um loop do sistema de arquivos. Por exemplo, esses comandos podem criar um loop com o link de retorno l:

mkdir -p /tmp/a/b
cd /tmp/a/b
ln -d /tmp/a l

Um sistema de arquivos com um loop de diretório tem profundidade infinita:

cd /tmp/a/b/l/b/l/b/l/b/l/b

Evitar um loop infinito ao atravessar uma estrutura de diretórios é um pouco difícil (embora, por exemplo, o POSIX exija findisso).

Um sistema de arquivos com esse tipo de link físico não é mais uma árvore, porque uma árvore não deve, por definição, conter um loop.

Eles quebram a ambiguidade dos diretórios pai

Com um loop do sistema de arquivos, existem vários diretórios pai:

cd /tmp/a/b
cd /tmp/a/b/l/b

No primeiro caso, /tmp/aé o diretório pai de /tmp/a/b.
No segundo caso, /tmp/a/b/lé o diretório pai de /tmp/a/b/l/b, que é o mesmo que /tmp/a/b.
Portanto, ele tem dois diretórios pai.

Eles multiplicam arquivos

Os arquivos são identificados por caminhos, após a resolução de links simbólicos. assim

/tmp/a/b/foo.txt
/tmp/a/b/l/b/foo.txt

são arquivos diferentes.
Existem infinitamente muitos outros caminhos do arquivo. Eles são os mesmos em termos de número de inodes, é claro. Mas se você não espera explicitamente loops, não há razão para verificar isso.

Um hardlink de diretório também pode apontar para um diretório filho ou um diretório que não é filho nem pai de nenhuma profundidade. Nesse caso, um arquivo filho do link seria replicado para dois arquivos, identificados por dois caminhos.

Seu exemplo

$ ln /Some/Direcoty /home/nischay/Hard-Directory
$ echo foo > /home/nischay/Hard-Directory/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ echo bar >> /Some/Direcoty/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ cat /Some/Direcoty/foobar.txt
foo
bar

Como os links flexíveis para diretórios funcionam então?

Um caminho que pode conter links flexíveis e até mesmo loops de diretório com links flexíveis geralmente é usado apenas para identificar e abrir um arquivo. Pode ser usado como um caminho linear normal.

Mas há outras situações em que os caminhos são usados ​​para comparar arquivos. Nesse caso, os links simbólicos no caminho podem ser resolvidos primeiro, convertendo-os em uma representação mínima e comumente acordada, criando um caminho canônico :

Isso é possível porque todos os links flexíveis podem ser expandidos para caminhos sem o link. Depois de fazer isso com todos os links flexíveis em um caminho, o caminho restante faz parte de uma árvore, onde um caminho é sempre inequívoco.

O comando readlinkpode resolver um caminho para seu caminho canônico:

$ readlink -f /some/symlinked/path

Links flexíveis são diferentes do que o sistema de arquivos usa

Um link flexível não pode causar todos os problemas porque é diferente dos links dentro do sistema de arquivos. Ele pode ser diferenciado dos links físicos e resolvido para um caminho sem links simbólicos, se necessário.
Em certo sentido, a adição de links simbólicos não altera a estrutura básica do sistema de arquivos - ela mantém, mas adiciona mais estrutura, como uma camada de aplicativo.


De man readlink:

 NAME
        readlink - print resolved symbolic links or canonical
        file names

 SYNOPSIS
        readlink [OPTION]... FILE...

 DESCRIPTION
        Print value of a symbolic link or canonical file name

        -f, --canonicalize
               canonicalize by  following  every  symlink  in
               every component of the given name recursively;
               all but the last component must exist
        [  ...  ]

1
Por que um link não pode fazer tudo isso?
Tanay

1
@Tanay Certo, isso poderia ajudar a expansão a compará-la a casos semelhantes com links flexíveis. Vou tentar.
Volker Siegel

Exatamente como isso pertence apenas aos diretórios? Pelo que entendi, esses problemas também são um problema para arquivos vinculados também. Além disso, vejo o hardlinking como uma maneira fácil de alterar a permissão de um determinado diretório para permitir que outros entrem, sem ter que permitir que eles também entrem na cadeia pai. Soa muito útil se você não tem a capacidade de adicionar / modificar grupos ...
inetknght

ótima resposta, mas então ... como a Apple resolveu esses problemas no Time Machine?
Damien

Parece muito interessante! Mas não sei nada sobre qual é o problema - você pode me dar uma dica?
Volker Siegel

77

"Você geralmente não deve usar links físicos de qualquer maneira" é muito amplo. Você precisa entender a diferença entre links físicos e links simbólicos e usar cada um conforme apropriado. Cada um possui seu próprio conjunto de vantagens e desvantagens:

Os links simbólicos podem:

  • Aponte para diretórios
  • Aponte para objetos inexistentes
  • Aponte para arquivos e diretórios fora do mesmo sistema de arquivos

Os links físicos podem:

  • Mantenha o arquivo que eles referenciam sendo excluído

Os links físicos são especialmente úteis na execução de aplicativos "copiar na gravação". Eles permitem que você mantenha uma cópia de backup de uma estrutura de diretórios, enquanto usa apenas espaço para os arquivos que mudam entre duas versões.

O comando cp -alé especialmente útil nesse sentido. Ele faz uma cópia completa de uma estrutura de diretórios, na qual todos os arquivos são representados por links físicos para os arquivos originais. Você pode então atualizar os arquivos na estrutura, e somente os arquivos que você atualizar ocuparão espaço adicional. Isso é especialmente útil ao manter backups multigeracionais.


41
em relação ao último parágrafo, se você editar o arquivo vinculado
marcin

32
Esta descrição de links físicos é bastante enganadora. É basicamente verdade que os links físicos "impedem que o arquivo que eles referenciam sejam excluídos", mas isso é apenas um efeito colateral dos links físicos. Certamente NÃO é verdade que você pode criar links físicos em um diretório, alterar o arquivo "original" e esperar que os links físicos apontem de alguma forma para o conteúdo antigo. De fato, a verdade norteadora dos links físicos é o fato de não ser um link, pelo menos não mais do que o "arquivo" original, que é apenas um nome apontando para um arquivo. Um link físico é simplesmente outro nome apontando para o mesmo arquivo.
matty

7
A ideia do backup é boa e eu uso muito isso, mas acho que os usuários devem ser avisados ​​de que a alteração de um arquivo também alterará o backup.
Mark

3
Caramba, um link simbólico não precisa apontar para nada. ln -s "Don't use this directory" READMEé legítimo. De fato, se você pensar bem, um diretório pode ser usado como um banco de dados relacional e não conter nenhum arquivo real.
Edward Falk

5
-1 Isso não responde à pergunta e algumas informações estão completamente erradas.
21418 wjandrea

43

Para sua informação, você pode obter o mesmo que links físicos para diretórios usando mount:

mount -t bind /var/www /home/user/workspace/www

Isso é muito perigoso, porque a maioria das ferramentas e programas não terá conhecimento da ligação . Certa vez, fiz algo como no exemplo acima e depois continuei rm -rf /home/user. Felizmente, não havia nada relevante /var/www.


6
Eu já usei mount --bind <src> <dest>. Use com cuidado para não limpar o src;)
kachar 17/02

1
Eu recebo:mount: unknown filesystem type 'bind'
Wizek 25/02

4
em Busybox, é #mount -o bind src dest
Mat M

@MatM same with Debian
hanshenrik

2
Se você precisar montar apenas para leitura, poderá definir permissões no ponto de montagem e evitar o rm -rfproblema. superuser.com/questions/320415/…
zanerock 26/01

19

A razão pela qual os diretórios de link físico não são permitidos é um pouco técnica. Essencialmente, eles quebram a estrutura do sistema de arquivos . Geralmente, você não deve usar links físicos de qualquer maneira. Links simbólicos permitem a maioria das mesmas funcionalidades sem causar problemas (por exemplo ln -s target link).


17
Links físicos têm bons casos de uso. Dizer que você geralmente não deve usá-los é um pouco amplo demais.
Sander Steffann

4
+2 por fornecer o link que realmente responde à pergunta do OP (e à minha), -1 por emitir uma opinião ("Você geralmente não deve usar links físicos de qualquer maneira" - se houver links para apoiá-lo, tudo bem). O que foi bom, porque eu não posso dar +2 de qualquer maneira. ; D
msb 14/01

3
o link "eles quebram a estrutura do sistema de arquivos" não funciona.
Charlie Parker

5
Tente resumir o conteúdo do link na resposta e mantenha o link como referência. Essa é uma boa prática do Stack Exchange para evitar a podridão do link, obrigado.
Oxwivi

3
bem feito @CharlieParker; melhor comentário irônico não intencional de todos os tempos :)
Eliran Malka 12/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.