What happens when I kill 'cp'? Is it safe and does it have any consequences?

Question

What are the consequences for a ext4 filesystem when I terminate a copying cp command by typing Ctrl + C while it is running?

Does the filesystem get corrupted? Is the partition's space occupied by the incomplete copied file still usable after deleting it?

And, most importantly, is terminating a cp process a safe thing to do?

Answer 1

This is safe to do, but naturally you may not have finished the copy.

When the cp command is run, it makes syscalls that instruct the kernel to make copies of the file. A syscall, or system call, is a function that an application can use to requests a service from the kernel, such as reading or writing data to the disk. The userspace process simply waits for the syscall to finish. If you were to trace the calls from cp ~/hello.txt /mnt, it would look like:

open("/home/user/hello.txt", O_RDONLY)           = 3
open("/mnt/hello.txt", O_CREAT|O_WRONLY, 0644)   = 4
read(3, "Hello, world!\n", 131072)               = 14
write(4, "Hello, world!\n", 14)                  = 14
close(3)                                         = 0
close(4)                                         = 0

This repeats for each file that is to be copied. No corruption will occur because of the way these syscalls work. When syscalls like these are entered, the fatal signal will only take effect after the syscall has finished, not while it is running (in fact, signals only arrive during a kernelspace to userspace context switch). Note that some signals, like read(), can be terminated early.

Because of this, forcibly killing the process will only cause it to terminate after the currently running syscall has returned. This means that the kernel, where the filesystem driver lives, is free to finish the operations that it needs to complete to put the filesystem into a sane state. Any I/O of this kind will never be terminated in the middle of operation, so there is no risk of filesystem corruption.

Answer 2

Since cp is a userspace command, this does not affect filesystem integrity.

You of course need to be prepared that at least one file will not have been copied completely if you kill a runnning cp program.

Answer 3

forest's answer, albeit pretty (and in many cases correct) isn't what you'll see on modern systems⁰. They're right – under no circumstances would this corrupt your file system. But under no practical circumstances would you get half a copy these days!

Assume I do this (just to generate a large file yesfile, and copy it to a file copy (doesn't have to be on the same file system), while logging all the system calls mady by cp):

cd /tmp
yes | head -n$((10**7)) > yesfile
strace -o strace.output cp yesfile copy

I get a different picture: the userland process cp does not actually read the content of the file and does not write it to another file; that would be bad, performance-wise: it would require at least two context switches! The userland programm calls read, switch, gets data, calls write, switch; rinse and repeat if the file is larger than a single read-buffer. Now this exact repeating model, reading only a buffer of limited size, is what could lead to half-copied files on interruption.

Instead, it uses the copy_file_range system call (see trace below¹); man copy_file_range tells us:

The copy_file_range() system call performs an in-kernel copy between two file descriptors without the additional cost of transferring data from the kernel to user space and then back into the kernel. It copies up to len bytes of data from the source file descriptor fd_in to the target file descriptor fd_out, overwriting any data that exists within the requested range of the target file.

So, there is an atomic copy-this-file system call, which is usually used, so interrupting cp can not interrupt the copying.

---

Things get even better if your source and target file system are the same, and Btrfs, CIFS, NFS 4.2, OCFS2, overlayfs, or XFS^source (at point of writing, only for these Linux has the reflink feature): if

ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3)

succeeds, the system doesn't need to copy the file contents at all – instead, just the list of blocks belonging to the source file is copied to the target file; each block has a reference counter that gets increased, so the moment any process writes to either of these files, the file system transparently does a copy-on-write on that. So, these things are even more atomic!

---

⁰ At least, if my GNU coreutils 8.32 with fedora 34's backported copy_file_range patches /Linux 5.13.5 are considered modern.
¹ relevant strace output

 156   │ newfstatat(AT_FDCWD, "yesfile", {st_mode=S_IFREG|0644, st_size=20000000, ...}, 0) = 0
 157   │ newfstatat(AT_FDCWD, "copy", 0x7fff982d5e70, 0) = -1 ENOENT (No such file or directory)
 158   │ openat(AT_FDCWD, "yesfile", O_RDONLY)   = 3
 159   │ newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=20000000, ...}, AT_EMPTY_PATH) = 0
 160   │ openat(AT_FDCWD, "copy", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
 161   │ newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
 162   │ ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3) = -1 EOPNOTSUPP (Operation not supported)
 163   │ fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
 164   │ mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0be58ca000
 165   │ uname({sysname="Linux", nodename="workhorse", ...}) = 0
 166   │ copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = 20000000
 167   │ copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = 0
 168   │ close(4)                                = 0
 169   │ close(3)                                = 0
 170   │ munmap(0x7f0be58ca000, 139264)          = 0