O que acontece quando eu mato 'cp'? É seguro e tem alguma consequência?

É seguro fazer isso, mas naturalmente você pode não ter terminado a cópia.

Quando o cpcomando é executado, ele faz syscalls que instruem o kernel a fazer cópias do arquivo. Uma syscall, ou chamada de sistema, é uma função que um aplicativo pode usar para solicitar um serviço do kernel, como ler ou gravar dados no disco. O processo de espaço do usuário simplesmente espera que a syscall termine. Se você rastrear as chamadas de cp ~/hello.txt /mnt, ficaria assim:

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

Isso se repete para cada arquivo que deve ser copiado. Nenhuma corrupção ocorrerá devido à maneira como essas syscalls funcionam. Quando syscalls como essas são inseridas, o sinal fatal só terá efeito após a syscall terminar , não enquanto estiver em execução (na verdade, os sinais só chegam durante uma troca de contexto de kernelspace para userspace). Observe que alguns sinais, como read(), podem ser encerrados antecipadamente.

Por causa disso, matar o processo forçosamente só fará com que ele seja encerrado após o retorno da syscall em execução no momento. Isso significa que o kernel, onde o driver do sistema de arquivos reside, é livre para concluir as operações que precisa concluir para colocar o sistema de arquivos em um estado são. Qualquer E/S desse tipo nunca será encerrada no meio da operação, portanto, não há risco de corrupção do sistema de arquivos.

Como cpé um comando de espaço do usuário, isso não afeta a integridade do sistema de arquivos.

É claro que você precisa estar preparado para que pelo menos um arquivo não tenha sido copiado completamente se você matar um cpprograma em execução.

a resposta da floresta , embora bonita (e em muitos casos correta) não é o que você verá nos sistemas modernos⁰. Eles estão certos – sob nenhuma circunstância isso corromperia seu sistema de arquivos. Mas sob nenhuma circunstância prática você receberia metade de uma cópia hoje em dia!

Suponha que eu faça isso (apenas para gerar um arquivo grande yesfilee copiá-lo para um arquivo copy(não precisa estar no mesmo sistema de arquivos), enquanto registra todas as chamadas do sistema por cp):

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

Eu recebo uma imagem diferente: o processo userland cpnão lê o conteúdo do arquivo e não o grava em outro arquivo ; isso seria ruim, em termos de desempenho: exigiria pelo menos duas trocas de contexto! O programa userland chama read, switch, obtém dados, chama write, switch; enxágue e repita se o arquivo for maior que um único buffer de leitura. Agora, esse modelo de repetição exato, lendo apenas um buffer de tamanho limitado, é o que pode levar a arquivos parcialmente copiados na interrupção.

Em vez disso, ele usa a copy_file_rangechamada do sistema (veja o rastreamento abaixo¹); man copy_file_rangediga-nos:

A copy_file_range() chamada do sistema executa uma cópia no kernel entre dois descritores de arquivo sem o custo adicional de transferir dados do kernel para o espaço do usuário e depois de volta para o kernel. Ele copia até lenbytes de dados do descritor de arquivo de origem fd_inpara o descritor de arquivo de destino fd_out, substituindo quaisquer dados que existam dentro do intervalo solicitado do arquivo de destino.

Portanto, há uma chamada de sistema de cópia-este-arquivo atômica, que geralmente é usada, portanto, interromper cpnão pode interromper a cópia.

As coisas ficam ainda melhores se o seu sistema de arquivos de origem e destino forem os mesmos, e Btrfs, CIFS, NFS 4.2, OCFS2, overlayfs ou XFS ^source (no momento da escrita, apenas para esses Linux tem o recurso reflink): se

ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3)

for bem-sucedido, o sistema não precisa copiar o conteúdo do arquivo – em vez disso, apenas a lista de blocos pertencentes ao arquivo de origem é copiada para o arquivo de destino; cada bloco tem um contador de referência que é aumentado, portanto, no momento em que qualquer processo grava em qualquer um desses arquivos, o sistema de arquivos faz uma cópia na gravação de forma transparente. Então, essas coisas são ainda mais atômicas!

⁰ Pelo menos, se meus GNU coreutils 8.32 com os copy_file_range patches de backport do fedora 34 /Linux 5.13.5 forem considerados modernos.
¹ saída de rastreamento relevante

 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