eu tentei
xtricman⚓ArchVirtual⏺️~?ls /proc/self/fd/ -l
Total 0
lrwx------ 1 xtricman users 64 1月 16 16:34 0 -> /dev/pts/0
lrwx------ 1 xtricman users 64 1月 16 16:34 1 -> /dev/pts/0
lrwx------ 1 xtricman users 64 1月 16 16:34 2 -> /dev/pts/0
lrwx------ 1 xtricman users 64 1月 16 16:34 3 -> '/home/xtricman/a (deleted)'
lr-x------ 1 xtricman users 64 1月 16 16:34 4 -> /proc/1273/fd
xtricman⚓ArchVirtual⏺️~?ln /proc/self/fd/3 b
ln: failed to create hard link 'b' => '/proc/self/fd/3': Invalid cross-device link
Como o inode ainda está no disco, como posso recriar um nome para ele? E se não houver descrição de arquivo aberto apontando para esse inode, mas esse inode estiver mapeado? Como posso restaurá-lo nesse caso?
Você não deveria ser capaz de fazer isso (mas leia abaixo para uma exceção interessante).
Se o kernel permitisse que isso acontecesse, uma chamada como:
teria sucesso mesmo quando o inode referenciado por
fd
tem uma contagem de links de 0, quando feito por um processo comCAP_DAC_READ_SEARCH
caps.Mas o kernel está impedindo ativamente que isso aconteça, sem levar em consideração os recursos ou privilégios do processo que o faz.
Isso também está documentado na página de manual:
com base na fonte do kernel, parece não haver outra exceção além do
O_TMPFILE
.O_TMPFILE
está documentado na página deopen(2)
manual; abaixo está um pequeno exemplo baseado nisso:Você poderia simplesmente
cat
esse descritor de arquivo:Você não pode
ln
criar um link físico com esse arquivo porque os links físicos não podem abranger sistemas de arquivos, e/proc
é um sistema de arquivos virtual (procfs
), e mesmo dentro de/proc
, o que você pode fazer é restrito (o conteúdo reflete o estado do kernel, então você não pode realizar operações arbitrárias).