O que acontece se um arquivo é modificado enquanto você o copia?

19

Qual é o efeito de copiar um arquivo, digamos fileA.big (900mb) do local B para o localC. Se durante essa operação cp, digamos 35% durante o processo, fileA.big for anexado com novas informações e crescer de 900mb para 930mb.

Qual é o resultado da cópia final (ou seja, arquivoA.big no localC)?

E se a cópia estiver concluída em cerca de 70% e o arquivo original for atualizado, mas desta vez truncado para 400mb (ou seja, o progresso da cópia estiver além do ponto de truncamento), qual é o resultado da cópia final?

Referindo-se a um sistema operacional Linux em um sistema de arquivos ext3 / ext4. Sem volume sombra mágica etc .. Simplesmente velho cp. Curiosidade provocada pela cópia de arquivos couchdb ao vivo para backup, mas mais interessados em cenários gerais do que em casos de uso específicos.

cp file-copy

— Mâtt Frëëman
fonte

Obrigado por perguntar este. Meu 'conhecimento' era principalmente um palpite ... até agora.

— tshepang

10

Se fileA.bigcrescer durante a cópia, a cópia incluirá os dados que foram anexados.

Se o arquivo for truncado mais curto do que o local da cópia, a cópia será cancelada exatamente onde está e o arquivo de destino conterá o que foi copiado até o momento em que foi cancelada.

— Patrick
fonte

27

Patrick está mais ou menos correto, mas eis o porquê. A maneira como você copia um arquivo no UNIX funciona assim:

Tente ler alguns (mais) bytes de fileA.
Se não conseguimos obter bytes porque estamos no (ou passado) final do arquivo, estamos prontos; Sair.
Caso contrário, escreva os bytes fileBe retorne à etapa 1.

Sabendo disso, e sabendo que é tão simples assim, vamos ver alguns casos extremos.

Assim que encontrarmos o final do arquivo, a cópia será concluída. Então, digamos que nosso arquivo esteja crescendo durante a cópia, mas está crescendo mais lentamente do que o copiado. O programa de cópia continuará além do tamanho do arquivo original, pois, quando chegar lá, haverá mais no arquivo. Mas, em algum momento, ele alcança o final do arquivo e sabe que está no final porque não pode ler mais bytes no momento . Portanto, ele termina ali mesmo que o arquivo esteja prestes a crescer ainda mais.

Se o arquivo estiver truncado, o programa de cópia diz "Whoa, já terminei o final do arquivo!" e sai.

E se partes do arquivo estão sendo atualizadas aleatoriamente por, digamos, um programa de banco de dados :-), sua cópia será uma mistura de dados antigos e novos, porque os dados não são todos copiados ao mesmo tempo. O resultado provavelmente será uma cópia corrompida, e é por isso que geralmente não é uma boa ideia fazer cópias de bancos de dados ativos.

(Dito isso, não estou familiarizado com o CouchDB e é possível criar um banco de dados para resistir a esse tipo de corrupção. Mas é melhor ter certeza absoluta.)

— Jander
fonte

Boa explicação. BTW, isso sempre me surpreendeu por que isso é possível em sistemas operacionais UNIX sem obter a mensagem de erro típica conhecida do Windows ("Não é possível acessar o arquivo - arquivo em uso"). Você nem conseguia reproduzir um arquivo MP3 que já havia sido excluído. enquanto estiver jogando. No Unix, você pode (surpreendentemente) - sem problemas. Eu acho que os sistemas operacionais baseados em UNIX sempre funcionam com cópias de backup dos arquivos, então isso é possível.

— Syntaxerror 26/09/13

1

Na verdade, a capacidade de ler um arquivo excluído vem de um recurso UNIX diferente: no UNIX, arquivos e nomes de arquivos são coisas diferentes. Quando você exclui um arquivo, o que realmente está fazendo é excluir um "link" nomeado para o arquivo. Quando um programa abre um arquivo, isso também conta como um link. O sistema excluirá o arquivo em si somente quando não houver mais links.

— Jander

Portanto, se o arquivo crescer mais rápido do que podemos copiá-lo, o cp nunca será encerrado? Sei que isso é improvável, pois o que quer que seja gravado no arquivo teria que ser capaz de gravá-lo, mais rapidamente do que o cp pode ler.

— Bladt