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?

  • 1
    Keep in mind that while the answers are correct for ext4, filesystems without journaling may not be as safe. – Ave Sep 2 '18 at 1:32
  • 3
    @Ave Journaling has nothing to do with this. The syscalls are atomic regardless of what filesystem you use. Journaling is useful in situations where power may be abruptly lost. – forest Sep 2 '18 at 7:14

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 is a function that an application can call that 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, it would look something 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. Because of this, forcibly killing the process will only cause it to terminate after the currently running syscall has finished. 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, making them atomic operations.

Interestingly, this is why commands like cp may not terminate immediately when they are killed. If you are copying a very large file and kill it, even with SIGKILL, the process will still run until the current syscall finishes. With a large file, this may take a while, as the process will be in an uninterruptible state.

  • 2
    @qwr That's most likely part of the glibc library, not cp itself. It has various file access functions that internally use that as a value. – forest Sep 1 '18 at 21:03
  • 2
    Great answer! I'd never realized that there's a delay in terminating a cp after SIGKILLing it, even while dealing with large files... maybe the duration of those uninterruptible atomic operations of a process is too short. Does the same explanation work for killing dd and other disk-reading/writing processes? – Seninha Sep 1 '18 at 21:35
  • 1
    @Seninha The operations are pretty brief because the accesses are cached, so you can copy a lot more data per second than your drive can actually handle, if done in bursts. If the file is really big and on a slow medium, then the cache can fill up and killing the process can take some time. As for killing dd, that depends on what bs you set for it. If it's only 512 (the default), then it should terminate quickly. If it's larger, then it may take a bit longer. – forest Sep 1 '18 at 21:37
  • 3
    @qwr 128kb chunks are hardwired default in coreutils when reading from blockdevices, this is done in effort to minimize syscalls. Analysis is given in the coreutils source: git.savannah.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h – Fiisch Sep 2 '18 at 11:52
  • 1
    @AndrewHenle Perhaps I should have said that it's the filesystem metadata which is atomic. You are correct that a write may be partial. – forest Sep 4 '18 at 19:25

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.

  • 14
    Why the downvote? Just because it’s schily? – Stephen Kitt Sep 1 '18 at 13:54
  • 6
    There definitely seems to be at least one person that downvotes all my answers. Do you know of a way to find out who did the downvote? – schily Sep 1 '18 at 14:02
  • 2
    Not even moderators can find out who made specific votes - that is understandably restricted to SO employees. You can use the "contact us" link to ask them to investigate. – Philip Kendall Sep 1 '18 at 14:06
  • 1
    It would be pretty sad if a userspace program were able to compromise filesystem integrity. Note: Of course, there can be, there have been, and there will be bugs in filesystem implementations. Note #2: Also, of course, userspace programs running with elevated privileges (e.g. CAP_SYS_RAWIO in Linux or the equivalent in other OSs) that give them direct access to the underlying device of the filesystem (e.g. sudo dd if=/dev/urandom of=/dev/sda1) may wreak all sorts of havoc. – Jörg W Mittag Sep 1 '18 at 18:18
  • 3
    And if a filesystem was buggy enough to get corrupted after an interrupted cp, it would probably get corrupted from a finished cp too... – ilkkachu Sep 1 '18 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.