Como desvincular (remover) o link especial "." Criado para uma pasta?

No Linux, quando você cria uma pasta, ele cria automaticamente dois links físicos para o inode correspondente. Uma que é a pasta que você pediu para criar, a outra é a .pasta especial desta pasta.

Exemplo:

$ mkdir folder
$ ls -li
total 0
124596048 drwxr-xr-x    2 fantattitude  staff    68 18 oct 16:52 folder
$ ls -lai folder
total 0
124596048 drwxr-xr-x  2 fantattitude  staff   68 18 oct 16:52 .
124593716 drwxr-xr-x  3 fantattitude  staff  102 18 oct 16:52 ..

Como você pode ver, ambos foldere .dentro foldertêm o mesmo número de inode (mostrado com a -iopção).

Existe alguma maneira de excluir este .link especial ?

É apenas para experimentação e curiosidade. Também acho que a resposta pode se aplicar a ..arquivos especiais também.

Eu tentei olhar para o rmhomem, mas não consegui encontrar nenhuma maneira de fazê-lo. Quando tento remover .tudo o que recebo é:

rm: "." e ".." não podem ser removidos

Estou realmente curioso sobre o modo como essas coisas funcionam, para não deixar de ser muito detalhado sobre o assunto.

EDIT: Talvez eu não tenha esclarecido minha postagem, mas quero entender o mecanismo subjacente responsável pelos .arquivos e as razões pelas quais eles não podem ser excluídos.

Eu sei que o padrão POSIX não permite uma pasta com menos de 2 hardlinks, mas realmente não entendo o porquê. Quero saber se seria possível fazê-lo de qualquer maneira.

É tecnicamente possível excluir ., pelo menos nos sistemas de arquivos EXT4. Se você criar uma imagem do sistema de arquivos test.img, monte-a e crie uma testpasta e desmonte-a novamente, poderá editá-la usando debugfs:

debugfs -w test.img
cd test
unlink .

debugfsnão reclama e exclui a .entrada de diretório no sistema de arquivos. O testdiretório ainda é utilizável, com uma surpresa:

sudo mount test.img /mnt/temp
cd /mnt/temp/test
ls

mostra apenas

..

então .realmente se foi. No entanto cd ., ls ., pwdainda se comportam como de costume!

Eu já tinha feito este teste usando rmdir ., mas que exclui inode do diretório ( enormes graças a BowlOfRed para apontar isto ), o que deixa testuma entrada de diretório pendurado e é a verdadeira razão para os problemas encontrados. Nesse cenário, a testpasta se torna inutilizável; depois de montar a imagem, correr lsproduz

ls: cannot access '/mnt/test': Structure needs cleaning

e o log do kernel mostra

EXT4-fs error (device loop2): ext4_lookup:1606: inode #2: comm ls: deleted inode referenced: 38913

A execução e2fscknessa situação na imagem exclui testcompletamente o diretório (o inode do diretório se foi, portanto, não há nada para restaurar).

Tudo isso mostra que .existe como uma entidade específica no sistema de arquivos EXT4. Tive a impressão do código do sistema de arquivos no kernel que ele espera .e ..exista, e avisa se eles não o fazem (veja namei.c), mas com o unlink .teste baseado em eu não vi esse aviso. e2fscknão gosta da .entrada de diretório ausente e oferece uma correção:

$ /sbin/e2fsck -f test.img
e2fsck 1.43.3 (04-Sep-2016)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Missing '.' in directory inode 30721.
Fix<y>?

Isso recria a .entrada do diretório.

Não há como remover esta entrada de diretório. A .entrada significa "este diretório", a ..entrada significa "diretório pai deste diretório". Na verdade, eles não são links físicos, é assim que a estrutura de diretórios é criada / representada.

Conforme descrito nas notas do Lion sobre o código-fonte do Unix 6o Unix inicial tinha um arquivo de disco no qual os arquivos e diretórios eram representados no disco por estruturas de inode. Havia um bit especial que indicava que o conteúdo do arquivo era um diretório. Cada inode tinha um link para seu inode proprietário que permitia que um arquivo soubesse em que diretório ele estava. A exceção era o diretório '/' que era seu. Havia também um link para o conteúdo. Se um inode não tivesse conteúdo, ele poderia ser retornado à lista livre. Como um diretório era apenas um arquivo abençoado, mesmo um diretório vazio precisava ter conteúdo para impedir que fosse coletado como lixo. Assim, o .. foi o link do inode para o inode pai e o. estava lá para indicar que o diretório ainda era utilizável. O rmdir (chamando unlink) pode remover o arquivo.

Como diz a possível duplicata da resposta do post , o padrão POSIX especifica que, se o rmdir tentar remover o diretório atual, ele falhará.

Com qualquer coisa que você constrói, você precisa ter uma base. É difícil definir caminhos relativos sem uma maneira de dizer 'aqui'. Então o '.' é definido como 'aqui'.

Além disso, você pode remover 'ponto' e 'ponto ponto'. Escreva seu próprio sistema operacional que não os define. Embora o Unix (e por extensão o Mac OSX), o Linux e até o MS DOS e o Windows usem dot e dotdot.

TL; DR - 'ponto' está na definição do sistema operacional.