NAME ln -- make a link
SYNOPSIS ln name1[ name2 ]
DESCRIPTION ln creates a link to an existing file name1.
If name2 is given, the link has that name;
Desde 1971 Unix First Edition Manuais .
Há uma segunda forma simples e simples de sintaxe.
edit: eu coloquei ARQUIVO ou ARQUIVO em vez de TARGET --- ver comentários etc. ver também muito disso na parte inferior, abordando o iceberg, duro e mole de ln, não apenas a ponta do mesmo.
Então o GNU lntem isso:
ln [opt] FILENAME
In the 2nd form, create a link to FILENAME in the current directory.
onde você não precisa do nome do link. Depois de ln -s /usr/lib/modulesobter um
modules -> /usr/lib/modules
com o mesmo nome que FILENAME ("destino" ou "origem"), exatamente onde você está. Sem escolha, sem confusão.
Agora, se você é mais exigente e deseja que o link seja criado com outro nome e / ou outro local , adicione esse desejo como nome ou caminho. O alvo real vem em primeiro lugar, a fantasia extra, o novo nome do link, em segundo.
Ou você diz: "Conheço essa notação de flecha nos ls -llinks. Não tenho uma flecha no shell para mostrar a direção do meu link. Portanto, tenho que mudar isso".
Você o cria em uma direção, para poder usá-lo na outra.
(FIM DA PARTE RESPOSTA-PERGUNTA)
Em outro nível, a própria palavra "link" carrega um profundo duplo significado oculto. Os links simbólicos vieram mais tarde; portanto, nos primeiros dias, um link era apenas um link. Não havia macio e duro, nenhuma -sopção. E agora eu até uso o simbolismo fonte-alvo:
mv A B --- move the whole file to B (dir or new name)
cp A B --- copy whole file (mv and cp are "the same" here)
ln A B --- copy whole file MINUS data blocks (=copy only inode and name), and increase "link count" for track keeping
Nesta fase, existem links, mas não são rígidos e flexíveis, e ls -lnão mostram setas, porque não há direção em um link (rígido). Um "link" naquele estágio da evolução do unix significava que o nome do arquivo "B" (entrada de diretório "B") no sistema de arquivos aponta para o mesmo inode que o nome do arquivo "A" está apontando.
Os arquivos A e B são "vinculados" juntos, porque compartilham os mesmos blocos. Portanto, agora com todas as rm, o kernel precisa verificar: eu excluo / libero os blocos desse arquivo no disco ou existe outro arquivo vinculado aos mesmos blocos? Para isso, é usado um contador de links.
Digamos que você queira manter um arquivo grande em / tmp grom sendo excluído e restaurado ln /tmp/bigfile. Agora você tem um grande arquivo grande no seu diretório de trabalho. Após limpar / tmp e remover o "original", você continua usando os mesmos blocos de dados. Você não recebe um link morto ou danificado, você tem um arquivo normal. Apontar para nenhum arquivo, mas apenas o sistema de arquivos bloqueia como qualquer entrada de diretório. Somente agora "limpeza" / tmp não é tão eficiente quanto antes. Parece vazio, mas os blocos da partição não são liberados.
Mesmo que um link físico não custe o espaço em si, como o cp, indiretamente, pode.
Adicionando ln -sà sequência acima:
ln -s A B --- copy only the file's name to "B"
Agora "B", o link virtual, possui apenas uma sequência com um nome de caminho. Esta é uma informação "suave". Tecnicamente, "A" e "B" não estão relacionados. Mas ainda assim B é um "link" no novo sentido de que você pode usar esse nome de caminho armazenado como um atalho para "A". Agora é "um link para A" (ponto final) e não "vinculado ao inode do arquivo A"
Ambos os tipos de links podem confundir não apenas humanos, mas também o kernel / fs. A página de manual de 1971 observa: "ERROS: os links são copiados duas vezes e restaurados como arquivos separados com inodes separados".
Links físicos para diretórios (raros / não permitidos) podem facilmente levar a um entupimento.
Soft links para diretórios (muito comuns) podem levar a loops eternos - precisam ser reconhecidos pelos utilitários / kernel.
Exemplo prático em bash
Começando com um arquivo regular "F" ...
ln F Fhard
... torna Fhard do mesmo tamanho que F, mas ambos aparecem agora em um vermelho escuro SEM flechas ls -l --color. Devido à statexibição de "Links: 2" em conexão com "Inode: xyz". A vinculação física F transforma o próprio F em um link físico. Ambos são / permanecem tipo de arquivo "arquivo regular". Mas ambos têm um inode com uma contagem de links acima de 1.
ln -s F Fsoft
... cria um pequeno arquivo "irregular" "Fsoft" com o tipo de arquivo "link simbólico" --- ainda mais economia de espaço que um diretório vazio. A ls -lnão mostra nada de especial para "F". Para o Fsoft, o tamanho mostrado é de 1 byte, pois a string é 'F' e Fsoft -> Fé exibida como nome. Não é necessário colorir um link virtual para reconhecê-lo. Porque, na forma abreviada, ls -Fvocê @
anexa uma cadeia em espiral :Fsoft@
Com ls -lisso fica assim:
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 F
-rw-r--r-- 2 root root 6070340 Sep 16 16:28 Fhard
lrwxrwxrwx 1 root root 1 Sep 16 16:31 Fsoft -> F
Fhard tem tamanho e tipo de F.
O Fsoft tem o nome de F e o tamanho do nome de F como tamanho e um tipo de arquivo diferente.
Curto ls -sF:
5932 F 5932 Fhard 0 Fsoft@
adicionar --block-size=1também não produz os mesmos tamanhos. O Fsoft tem tamanho "um byte, zero bloco". F e Fhard se desviam em paralelo:
6074368 F 6074368 Fhard 0 Fsoft@
Para ver se o Fsoft está pendurado ou não, lsuse cores.
ORPHAN 40;31;01 # symlink to nonexistent file, or non-stat'able file
ae chamab"