On Thu, 12 Jul 2001, Heber Blain Goncalves wrote:
> Sempre me intriguei com a real diferenca entre os links simbolicos e
> fixos. Hoje, por teste, comecei a criar alguns para visualizar as suas
> diferencas.
Um arquivo num filesystem compat�vel com os padr�es Unix tem um
elemento chamado de "inode". O inode � um numero inteiro e representa
a posi��o de uma estrutura de informa��o contida em �rea especial do
disco. As informa��es contidas num inode s�o:
owner
group
permiss�es
tamanho
tipo (arquivo regular, diret�rio, device, ...)
n�mero de links (quantos "usam" este inode)
data de cria��o
data de modifica��o (escrita)
data de acesso (leitura)
tabela de "datablocks" onde o conte�do do arquivo � armazenado
Um diret�rio � um inode.
O conte�do de um diret�rio (armazenado nos datablocks) cont�m uma
tabela de nomes e respectivos n�meros de inodes (s� o n�mero do inode,
o inode "mesmo" est� em outra �rea do disco).
Quando um nome+inode � armazenado num diret�rio, o "n�mero de links"
do inode � incrementado. Isso indica que o inode est� sendo usado por
pelo menos um arquivo em algum diret�rio.
"stat" � o nome da fun��o do kernel que faz acesso ao conte�do de um
inode. Um programa de mesmo nome, stat(1), recebe um nome de arquivo
e mostra as informa��es do inode deste arquivo.
"ls -i" mostra o n�mero do inode dos arquivos.
"ls -l" mostra o n�mero de links do inode logo ap�s as permiss�es.
Quando criamos um hardlink estamos criando um "nome de arquivo" em
"algum diret�rio" e associando a esse nome o mesmo inode de outro
arquivo:
ln arquivo_existente novo_link
O comando ln pega o n�mero do inode de "arquivo_existente" o usa
tamb�m para o "novo_link". As informa��es de owner/group e permiss�o
est�o no inode, e o usu�rio precisa apenas ter o direito de leitura no
diret�rio onde est� "arquivo_existente" para poder ler o n�mero do
inode deste arquivo, e ter direito de escrita no diret�rio de
"novo_link" para poder criar mais uma entrada no diret�rio.
Se o usu�rio quiser acessar o conte�do de "novo_link", o sistema vai
verificar as permiss�es do inode, e impedir a opera��o, se for
indevida.
Acessos ao conte�do de "novo_link" � id�ntico ao acesso do conte�do de
"arquivo_existente", pois afinal estamos acessando os datablocks de um
_mesmo_ inode.
Veja que mesmo o usu�rio n�o tendo acesso ao conte�do do arquivo, o
filesystem vai incrementar o "numero de links" do inode.
Quando deletamos um arquivo estamos removendo a entrada de nome+inode
num diret�rio, e decrementando o n�mero de links do inode.
Quando o n�mero de links de um inode cair para zero, e nenhuma task
estiver com o arquivo aberto, o filesystem libera o inode e os
datablocks usados.
� por essa caracter�stica que a chamada do kernel para a fun��o de
"deletar um arquivo" chama-se de fato "unlink" e n�o "delete" como
poderiamos esperar.
Curiosidade: quando criamos um diret�rio:
- o sistema reserva um inode novo para o novo diret�rio.
- criamos uma nova entrada "nome+inode" no diret�rio pai, o que
faz com que o n�mero de links do novo inode seja incrementado.
- � criado o diret�rio "." no novo diret�rio apontando para o
novo inode, o que faz com que n�mero de links do novo inode
seja incrementado.
- � criado o diret�rio ".." no novo diret�rio, sendo que o inode
desta entrada � o mesmo inode do diret�rio pai, portando o
n�mero de links do diret�rio pai � incrementado.
Resultado: o inode do novo diret�rio j� come�a com 2, e o n�mero de
links num diret�rio indica o "n�mero de subdiret�rios" que este
diret�rio possui (incluindo o . e ..).
Confirme com:
ls -ldi .
mkdir xxx
ls -ldi . xxx xxx/. xxx/..
rmdir xxx
ls -ldi .
E os "symbolic links"? Um symbolic link possui um inode pr�prio, mas
as permi��es s�o fixadas em "777". O datablock de um symbolic link
cont�m o path para o que desejamos linkar.
Quando executamos "ln -s xxx yyy":
- obtemos um novo inode
- o tipo de arquivo � "l", symbolic link
- as permiss�es s�o 777
- as demais informa��es do inode s�o particulares deste inode
- um datablock � alocado e o conte�do "xxx" � armazenado
- acrescentamos "yyy+inode" no diret�rio onde yyy vai existir,
o o inode do link simb�lico � incrementado
Se "xxx" n�o existe, isso � problema de quem for usar yyy. :)
As chamadas do filesystem de creat, open, read, e write v�o de fato
fazer acessos ao arquivo "xxx", j� unlink("y") remove o link
simb�lico. Quando for realizado o acesso nos datablocks do inode de
xxx, as permiss�es de acesso deste inode s�o verificadas.
De fato o filesystem "persegue" o conte�do de tantos links simb�licos
quantos existirem, at� chegar a um "n�o link simb�lico" ou a um link
simb�lico que aponta para um arquivo inexistente:
$ ln -s xxx yyy
$ ls -lid yyy
94791 lrwxrwxrwx 1 klein users 3 Jul 14 18:44 yyy -> xxx
$ cat yyy
cat: yyy: No such file or directory
$ date >yyy
$ ls -ldi xxx yyy
94792 -rw-r--r-- 1 klein users 29 Jul 14 18:45 xxx
94791 lrwxrwxrwx 1 klein users 3 Jul 14 18:44 yyy -> xxx
$ ln -s yyy zzz
$ ls -lid xxx yyy zzz
94792 -rw-r--r-- 1 klein users 29 Jul 14 18:45 xxx
94791 lrwxrwxrwx 1 klein users 3 Jul 14 18:44 yyy -> xxx
94793 lrwxrwxrwx 1 klein users 3 Jul 14 18:45 zzz -> yyy
$ cat zzz
Sat Jul 14 18:45:13 BRT 2001
$ rm xxx
$ cat zzz
cat: zzz: No such file or directory
$ date >zzz
$ ls -lid xxx yyy zzz
94792 -rw-r--r-- 1 klein users 29 Jul 14 18:46 xxx
94791 lrwxrwxrwx 1 klein users 3 Jul 14 18:44 yyy -> xxx
94793 lrwxrwxrwx 1 klein users 3 Jul 14 18:45 zzz -> yyy
O programa namei(1) "persegue" e mostra a cadeia de links simb�licos
da mesma maneira que o filesystem faz:
$ namei zzz
f: zzz
l zzz -> yyy
l yyy -> xxx
- xxx
--- Wagner [EMAIL PROTECTED]
Assinantes em 14/07/2001: 2259
Mensagens recebidas desde 07/01/1999: 122941
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
