Es técnicamente posible eliminar . , al menos en sistemas de archivos EXT4. Si crea una imagen de sistema de archivos en test.img , móntelo y cree un test carpeta, luego desmóntelo nuevamente, puede editarlo usando debugfs :
debugfs -w test.img
cd test
unlink .
debugfs no se queja y borra obedientemente el . entrada de directorio en el sistema de archivos. El test El directorio todavía se puede usar, con una sorpresa:
sudo mount test.img /mnt/temp
cd /mnt/temp/test
ls
muestra solo
..
entonces . realmente se ha ido. Sin embargo, cd . , ls . , pwd ¡Sigue comportándote como siempre!
Previamente había hecho esta prueba usando rmdir . , pero eso elimina el inodo del directorio (enorme gracias a BowlOfRed por señalar esto), lo que deja test una entrada de directorio colgante y es la verdadera razón de los problemas encontrados. En este escenario, el test entonces la carpeta se vuelve inutilizable; después de montar la imagen, ejecuta ls produce
ls: cannot access '/mnt/test': Structure needs cleaning
y el registro del kernel muestra
EXT4-fs error (device loop2): ext4_lookup:1606: inode #2: comm ls: deleted inode referenced: 38913
Ejecutando e2fsck en esta situación en la imagen borra el test directorio por completo (el inodo del directorio se ha ido, por lo que no hay nada que restaurar).
Todo esto demuestra que . existe como una entidad específica en el sistema de archivos EXT4. Me dio la impresión del código del sistema de archivos en el kernel que espera . y .. existir, y advierte si no lo hacen (ver namei.c ), pero con el unlink . -basado en la prueba No vi esa advertencia. e2fsck no le gusta el . faltante entrada de directorio y ofrece arreglarlo:
$ /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>?
Esto vuelve a crear el . entrada de directorio.
No hay forma de eliminar esta entrada de directorio. El . entrada significa "este directorio", el .. entrada significa "directorio principal de este directorio". En realidad, no son enlaces duros, así es como se crea/representa la estructura del directorio.
Como se describe en Notas de Lion sobre el código fuente de Unix 6 Los primeros Unix tenían un archivo de disco donde tanto los archivos como los directorios estaban representados en el disco por estructuras de inodos. Había un bit especial que indicaba que el contenido del archivo era un directorio. Cada inodo tenía un enlace a su inodo propietario que permitía que un archivo supiera en qué directorio estaba. La excepción era el directorio '/' que se poseía a sí mismo. También había un enlace a los contenidos. Si un inodo no tuviera contenido, podría devolverse a la lista libre. Dado que un directorio era solo un archivo bendito, incluso un directorio vacío tenía que tener contenido para evitar que se recolectara como basura. Por lo tanto, el .. era el enlace del inodo al inodo principal y el . estaba allí para indicar que el directorio aún era utilizable. rmdir (llamando a unlink) podría eliminar el archivo . directorio si no hubiera otros contenidos y el inodo se movería a la lista libre cuando no hubiera más referencias a él.