Eu li em muitos sites que, no Linux, links simbólicos (links flexíveis, links simbólicos) são como ponteiros que referenciam outro arquivo, o que pode esteja localizado em qualquer lugar (como atalhos do Windows). No entanto, quando verifico o uso do disco de uma pasta na qual há links simbólicos, há uma incompatibilidade entre o que meu gerenciador de arquivos diz e o que du
relata. No entanto, se eu digitar du -L
(-L, --dereference; dereference all symbolic links
na página de manual), a saída de du -L
e o tamanho que meu gerenciador de arquivos relata são os mesmos.
Minha pergunta é: se eu tiver um softlink para um arquivo grande, por exemplo, em meus home
partição, terei algum problema?
Exemplo:
Minha pasta /var/tmp
agora está vazia. Vamos criar um arquivo:
$ cat /some/file.txt > file.txt
$ du -ac
164 ./file.txt
168 .
168 total
E meu gerenciador de arquivos (Thunar, neste caso) relata
Tamanho: 1 item, totalizando 163.0 kB
Tudo certo. Agora, vamos criar um arquivo muito grande em /tmp
e um link simbólico para ele:
$ cat /dir/really_big.txt > /tmp/heavy.txt
$ du -a | grep heavy.txt
408 ./heavy.txt
$ ln -s /tmp/heavy.txt heavy.txt
$ du -ac
164 ./file.txt
0 ./heavy.txt
168 .
168 total
Está tudo bem por enquanto. Mas se eu abrir meu gerenciador de arquivos:
Tamanho: 2 itens, totalizando 570,3 kB
E finalmente:
$ du -acL
164 ./file.txt
408 ./heavy.txt
576 .
576 total
Se a partição na qual /var/tmp
está localizada for 1 GiB grande, e eu criar um link nela para um 1 GiB arquivo, ¿ meu disco rígido morre? Eu sei que du
produzirá 168 e Thunar 1 GiB, mas não sei qual é o certo.
Os links simbólicos ocupam espaço, é claro, mas apenas o espaço necessário para armazenar o nome e o destino, além de alguns bytes para outros metadados. O espaço ocupado por um link simbólico não depende do espaço ocupado pelo destino (afinal, o destino nem precisa existir).
Plain du
informa o espaço ocupado por uma árvore de diretórios no disco. du -L
informa o espaço que seria ocupado por uma árvore de diretórios se todos os links simbólicos fossem substituídos por seus destinos. O primeiro é geralmente a informação útil; por exemplo, é o espaço que você recuperaria se excluir a árvore e é (aproximadamente) o espaço necessário para fazer backup da árvore.
du
em uma árvore de diretórios mostra (geralmente) um pouco mais do que o total dos tamanhos de arquivo. Isso é devido a duas coisas. Primeiro, du
também conta com diretórios, que requerem um pouco de espaço para armazenar nomes e metadados de arquivos. Segundo, du
conta o espaço em disco ocupado por um arquivo, que pode ser diferente do tamanho do arquivo: o efeito mais comum é que os arquivos ocupam um número inteiro de blocos (4kB em uma instalação típica do Linux), portanto um arquivo de 1 byte pode aparecer como 4kB em saída; mas a compactação (como a forma primitiva fornecida por arquivos esparsos em praticamente todos os sistemas de arquivos unix) pode tornar o tamanho do arquivo maior que o uso do disco.
A partir dos números que você fornece, parece que o Thunar reporta a soma dos tamanhos dos arquivos na árvore de diretórios, seguindo os links simbólicos . Na verdade, está dizendo isso de maneira sutil - afirma que o tamanho total é de 570,3 kB, não que o uso do disco seja de 570,3 kB. O que não é aparente na interface do usuário ou na documentação é que Thunar segue links simbólicos ao calcular o tamanho.
Qual deles está "certo" é uma questão subjetiva. du
relata o uso do disco. Thunar relata o tamanho total seguindo links simbólicos. A criação de um link simbólico tem um impacto insignificante no uso do disco, mas, por definição, altera os links simbólicos de tamanho total após o relatório que Thunar relata.
Eu acho que por padrão seu gerenciador de arquivos está tentando obter o tamanho dos arquivos que os links flexíveis estão apontando, enquanto du
fornece o tamanho do diretório e dos links flexíveis, mas não dos arquivos que eles estão apontando para.
Esclarecer,
`du` -> size of directory + size of all the softlinks
`du -L` -> size of directory + size of all the files that the softlinks are pointing to.
Não tenho certeza se é isso que você estava perguntando, mas se for, acredito que essa poderia ser a resposta para sua pergunta.