What happens when you delete a file in Linux?

Modern desktop and graphical environments offer a trash folder. This location permits retrieving a "deleted" file before it is irrecoverably erased. When you're using a terminal, trash commands send files to the trash folder as a staging area. But what happens when you tell your Linux computer to delete a file with the rm command? Does it delete the file?

[ Keep your most commonly used commands handy with the Linux commands cheat sheet. ]

File removal

Different interactions occur when you delete a file, mainly depending on the filesystem (EXT4, XFS, BtrFS, and so on) the system uses. Without dwelling on filesystem specifics, it's always possible to monitor exactly what happens when you invoke the rm command.

First, create a test file named example.txt:

$ echo "This is a test file" > example.txt

Get some additional information about the file with the stat command:

$ stat example.txt
  File: example.txt
  Size: 26              Blocks: 8
  IO Block: 4096   regular file
Device: fd00h/64768d
Inode: 17198515    Links: 1
Access: (0664/-rw-rw-r--)
Uid: ( 1001/testuser)
Gid: ( 1001/testuser)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2022-09-14 17:22:51.492026903 +0200
Modify: 2022-09-14 17:24:21.667609795 +0200
Change: 2022-09-14 17:24:21.667609795 +0200
 Birth: 2022-09-14 17:22:51.492026903 +0200

The stat command output displays the filesystem's block size, how many blocks the file uses, and so on. (Don't worry, this article does not require any math!)

The most important information in this example is the inode number. In this example, that's:

Inode: 17198515

What is an inode?

An inode holds metadata about a file. It includes the file's size, where to find the blocks that contain the file's contents, the file mode, and so on. Every file has a reference inode.

There are tools to find block information about a file. These commands are specific to the filesystem. For example, in XFS, it is the xfs_bmap command.

$ xfs_bmap example.txt
example.txt:
  0: [0..7]: 9343608..9343615

Remember those numbers. If you proceed with deletion, you're going to need them!

The strace command

A system call ("syscall" for short) is the programmatic way a program requests a service from the kernel. Strace is a powerful tool that allows you to trace the thin layer between user processes and the Linux kernel. To understand the interaction between the file and the syscall you make with rm, you can monitor the deletion process with strace:

$ strace --follow-forks \
--absolute-timestamps \
--syscall-times \
--no-abbrev \
--decode-fds -o /tmp/rm_log.txt \
--string-limit 1024 \
rm example.txt

Using /tmp/rm_log.txt as a record, you can see important information about the rm process execution. First, notice the process ID (PID):

1727 [...] execve("/usr/bin/rm", ["rm", "example.txt"],

You can also see that the system verifies the stat of the file with the syscall newfstatat:

1727  17:26:04.489674 newfstatat(AT_FDCWD, "example.txt", {st_dev=makedev(0xfd, 0), st_ino=17198515, st_mode=S_IFREG|0664, st_nlink=1, st_uid=1001, st_gid=1001, st_blksize=4096, st_blocks=8, st_size=26, st_atime=1663168971 /* 2022-09-14T17:22:51.492026903+0200 */, st_atime_nsec=492026903, st_mtime=1663169061 /* 2022-09-14T17:24:21.667609795+0200 */, st_mtime_nsec=667609795, st_ctime=1663169061 /* 2022-09-14T17:24:21.667609795+0200 */, st_ctime_nsec=667609795}, AT_SYMLINK_NOFOLLOW) = 0 <0.000004>

That's pretty cryptic. Here is what it means:

• st_ino=17198515: The inode number containing all the file metadata
• st_uid=1001, st_gid=1001: The user ID (UID) and group ID (GID) owner of the file
• st_blksize=4096: Block size dimension
• st_atime=1663168971: Time of last access
• st_mtime=1663169061: Time of last modification
• st_ctime=1663169061: Time of last status change

The executable rm has successfully accessed the file, as indicated by the W_OK marker:

1727  17:26:04.489705 faccessat(AT_FDCWD, "example.txt", W_OK) = 0 <0.000005>

Next, the process makes the unlinkat syscall:

1727  17:26:04.489724 unlinkat(AT_FDCWD, "example.txt", 0) = 0 <0.000062>

And the file is deleted from the folder:

$ ls -la
total 16
drwx------. 2 [...]  83 Sep 14 17:08 .
drwxr-xr-x. 4 [...]      35 Sep 13 16:46 ..
-rw-------. 1 [...] 508 Sep 13 18:22 .bash_history
-rw-r--r--. 1 [...]  18 Jun 20 13:31 .bash_logout
-rw-r--r--. 1 [...] 141 Jun 20 13:31 .bash_profile
-rw-r--r--. 1 [...] 376 Jun 20 13:31 .bashrc

The file doesn't exist anymore. Or does it?

The unlink syscall

The unlink syscall has deleted a name from the filesystem, possibly the file it refers to.

Here's more information from the unlink man page:

unlink() deletes a name from the filesystem.
If that name was the last link to a file and no processes have
the file open, the file is deleted and the space it was using
is made available for reuse.

Recover a deleted file

Earlier in the article, I used the xfs_bmap tool to obtain the block used by the file in the filesystem. That's about to become very useful because it's time to recover the deleted file.

First, use dd to read the previous blocks from the disk and redirect the output to the file recover.txt:

$ sudo dd if=/dev/mapper/rhel-root of=recover.txt count=8 skip=9343512
8+0 records in
8+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00012141 s, 33.7 MB/s

You've just built a stream of data from the hard drive with a dimension of 4096 bytes, but what's inside this file?

$ cat recover.txt
This is a test file......

The file has been recovered!

Delete with care

It may be either comforting or disconcerting that the file you deleted with rm isn't actually gone. Recovery depends on prior knowledge of a file's inode location or a brute-force search-and-recovery with specialized tools.

Understanding rm and the syscalls it relies upon is important knowledge to have. Now that you have it, you can make informed decisions about how you trash, delete, or shred files.