Is it possible to delete . and ..?
I read somewhere there are some patches for the linux kernel which let you do that. I have no idea where I read it and I don't know how to search for it because google and duckduckgo ignore the .s.
1 Answer
Technically, it is possible; for example, on an ext4 file system in e2test.img:
$ sudo mount e2test.img /mnt/temp
$ sudo mkdir /mnt/temp/dir{1,2}
$ sudo umount /mnt/temp
$ debugfs -w e2test.img
debugfs 1.45.6 (20-Mar-2020)
debugfs: unlink dir1/..
debugfs: unlink dir1/.
debugfs: quit
$ sudo mount e2test.img /mnt/temp
$ ls -a /mnt/temp/dir{1,2}
/mnt/temp/dir1:
/mnt/temp/dir2:
. ..
The shell isn’t particularly confused:
$ cd /mnt/temp/dir1
$ pwd
/mnt/temp/dir1
$ cd ..
$ pwd
/mnt/temp
As might be expected, e2fsck isn’t happy about this:
$ e2fsck e2test.img
e2fsck 1.45.6 (20-Mar-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Missing '.' in directory inode 113793.
Fix<y>? yes
Setting filetype for entry '.' in ... (113793) to 2.
Missing '..' in directory inode 113793.
Fix<y>? yes
Setting filetype for entry '..' in ... (113793) to 2.
Pass 3: Checking directory connectivity
'..' in /dir1 (113793) is <The NULL inode> (0), should be / (2).
Fix<y>? yes
Pass 4: Checking reference counts
Pass 5: Checking group summary information
e2test.img: ***** FILE SYSTEM WAS MODIFIED *****
e2test.img: 14/128016 files (0.0% non-contiguous), 18478/512000 blocks
The exact behaviour will depend on the specific file system being used. Some don’t even store . and .. entries, but emulate them instead (POSIX requires . and .. to be understood and resolve to the appropriate directories, but doesn’t require them to be physically present).
answered Jan 21, 2021 at 13:56
-
1POSIX doesn't require them. It requires
.to resolve to the current directory and..to resolve to the parent, but notreaddir()to include any of them in its result. Actually, the world would be a better place ifreaddir()no longer returned them. See also: austingroupbugs.net/view.php?id=1228Stéphane Chazelas– Stéphane Chazelas2021-01-21 13:59:54 +00:00Commented Jan 21, 2021 at 13:59 -
@Stéphane yes, I only wanted to explain why a file system would emulate them; thanks for the clarification, I’ve updated the answer.Stephen Kitt– Stephen Kitt2021-01-21 14:12:15 +00:00Commented Jan 21, 2021 at 14:12
-
I don't think it's good to conflate the emulation of
.and..when resolving paths (which is required by POSIX compat and is done by the kernel at VFS level) and their emulation of.and..when listing directories (which is done by most filesystems, though not required by POSIX, and not at all useful or reliable). If you re-created.as a named pipe or regular file indebugfs,stat .would still show it as a directory. A much better question IMHO would've been: what programs would break if filesystems no longer faked the.and..entries when listing directories?user313992– user3139922021-01-22 09:48:26 +00:00Commented Jan 22, 2021 at 9:48 -
In the (unlikely) case someone actually tries that, notice that
debugfsis a very blunt tool:mknod /dir/pipe pwill not create a named pipe inside the/dirdirectory, but one named/dir/pipe(yes, including the slashes as part of the filename) inside the current directory.user313992– user3139922021-01-22 10:42:47 +00:00Commented Jan 22, 2021 at 10:42
..refers to the parent directory, and.to the current directory?/foo/bar/and you manage to remove.. It may be you remove/foo/bar/; or it may be/foo/bar/still exists but there is no longer.in it..and.refer to. I wan't to remove.and..in the directory not the directory itself