¿Qué sucede si un archivo se modifica mientras lo está copiando?

19

¿Cuál es el efecto de copiar un archivo? Por ejemplo, fileA.big (900mb) de la ubicación B a la ubicación C. Si durante esa operación de cp, digamos 35% a través del proceso, fileA.big se agrega con nueva información y crece de 900mb a 930mb.

¿Cuál es el resultado de la copia final (es decir, fileA.big en locationC)?

¿Qué sucede si la copia tiene aproximadamente un 70% y el archivo original se actualiza pero esta vez se trunca a 400 mb (es decir, el progreso de la copia está más allá del punto de truncamiento), ¿cuál es el resultado de la copia final?

Refiriéndose a un sistema operativo Linux en un sistema de archivos ext3 / ext4. Sin volumen sombra mágica, etc. Simplemente viejo cp. La curiosidad se generó al copiar archivos de couchdb en vivo para la copia de seguridad, pero está más interesado en escenarios generales en lugar de casos de uso específicos.

cp file-copy

— Mâtt Frëëman
fuente

Gracias por preguntar esto. Mi "conocimiento" era principalmente una suposición ... hasta ahora.

— tshepang

10

Si fileA.bigse cultiva durante la copia, la copia incluirá los datos que se agregaron.

Si el archivo se trunca más corto de lo que está actualmente la copia, la copia se anulará justo donde está y el archivo de destino contendrá lo que se copió hasta el momento en que se anuló.

— Patricio
fuente

27

Patrick lo tiene más o menos correcto, pero he aquí por qué. La forma en que copia un archivo en UNIX funciona así:

Intenta leer algunos (más) bytes de fileA.
Si no pudimos obtener bytes porque estamos (o pasamos) al final del archivo, hemos terminado; dejar.
De lo contrario, escriba los bytes fileBy vuelva al paso 1.

Saber eso, y saber que es tan simple como eso, nos permite ver algunos casos de esquina.

Tan pronto como encontremos el final del archivo, la copia estará lista. Entonces, digamos que nuestro archivo está creciendo durante la copia, pero está creciendo más lentamente de lo que lo estamos copiando. El programa de copia seguirá pasando el tamaño del archivo original, porque para cuando llegue allí, hay más en el archivo. Pero en algún momento, se pone al día con el final del archivo, y sabe que está al final porque no puede leer más bytes en este momento . Por lo tanto, se cierra allí, incluso si el archivo está a punto de crecer aún más.

Si el archivo se trunca, el programa de copia dice "¡Vaya, ya he pasado el final del archivo!" y renuncia.

Y si partes del archivo se actualizan al azar mediante, por ejemplo, un programa de base de datos :-), entonces su copia será una mezcla de datos antiguos y nuevos, porque no todos los datos se copian al mismo tiempo. El resultado probablemente será una copia corrupta, por lo que generalmente no es una buena idea hacer copias de bases de datos en vivo.

(Dicho esto, no estoy familiarizado con CouchDB, y es posible diseñar una base de datos para que sea resistente a este tipo de corrupción. Pero lo mejor es estar absolutamente seguro).

— Jander
fuente

Buena explicación. Por cierto, esto siempre me ha sorprendido por qué esto es posible en sistemas operativos tipo UNIX sin recibir el típico mensaje de error conocido de Windows ("No se puede acceder al archivo - archivo en uso") Ni siquiera podía reproducir un archivo MP3 que ya se había eliminado mientras lo juegas. Bajo Unix, puedes (sorprendentemente), sin ningún problema. Supongo que los sistemas operativos basados en UNIX siempre funcionan con copias de seguridad de los archivos, por lo que esto es factible.

— syntaxerror

1

En realidad, poder leer un archivo eliminado proviene de una característica diferente de UNIX: bajo UNIX, los archivos y los nombres de archivo son cosas diferentes. Cuando elimina un archivo, lo que realmente está haciendo es eliminar un "enlace" con nombre al archivo. Cuando un programa abre un archivo, eso también cuenta como un enlace. El sistema eliminará el archivo solo cuando no le queden enlaces.

— Jander

Entonces, si el archivo crece más rápido de lo que podemos copiarlo, ¿cp nunca terminará? Me doy cuenta de que es poco probable, ya que lo que sea que escriba en el archivo tendría que poder escribir en el archivo, más rápido de lo que cp puede leer.

— Bladt