Cosa succede se un file viene modificato durante la copia?

19

Qual è l'effetto della copia di un file dire fileA.big (900mb) dalla posizione B alla posizioneC. Se durante l'operazione cp, dite il 35% attraverso il processo, fileA.big viene aggiunto con nuove informazioni e passa da 900mb a 930mb.

Qual è il risultato della copia finale (ovvero fileA.big in locationC)?

Che cosa succede se la copia raggiunge circa il 70% e il file originale viene aggiornato ma questa volta troncato a 400mb (ovvero l'avanzamento della copia supera il punto di troncamento), qual è il risultato della copia finale?

Riferendosi ad un SO Linux su un filesystem ext3 / ext4. Nessuna magia dell'ombra del volume ecc. Semplicemente vecchio vecchio cp. La curiosità scatenata dalla copia di file live da couchdb per il backup, ma più interessata a scenari generali piuttosto che a casi d'uso specifici.

cp file-copy

— Mâtt Frëëman
fonte

Grazie per avermelo chiesto. La mia "conoscenza" era principalmente un'ipotesi ... fino ad ora.

— Tshepang,

10

Se fileA.bigviene cresciuto durante la copia, la copia includerà i dati che sono stati aggiunti.

Se il file viene troncato più corto di quello in cui si trova attualmente la copia, la copia si interromperà esattamente dove si trova e il file di destinazione conterrà ciò che è stato copiato fino al momento in cui è stato interrotto.

— Patrick
fonte

27

Patrick ha più o meno corretto, ma ecco perché. Il modo in cui copi un file in UNIX funziona in questo modo:

Prova a leggere alcuni (più) byte da fileA.
Se non siamo riusciti a ottenere byte perché siamo alla (o passata) fine del file, abbiamo finito; smettere.
In caso contrario, scrivere i byte su fileBe tornare al passaggio 1.

Sapendo questo, e sapendo che è così semplice, ci permette di vedere alcuni casi d'angolo.

Non appena troviamo la fine del file, la copia è terminata. Supponiamo quindi che il nostro file cresca durante la copia, ma cresca più lentamente di quanto non lo stiamo copiando. Il programma di copia continuerà a superare le dimensioni del file originale, perché quando arriva lì, c'è di più nel file. Ma a un certo punto, raggiunge la fine del file e sa che è alla fine perché non è in grado di leggere altri byte in questo momento . Quindi si chiude proprio lì, anche se il file sta per crescere ulteriormente.

Se il file viene troncato, il programma di copia dice "Whoa, ho superato la fine del file!" e si chiude.

E se parti del file vengono aggiornate casualmente da, per esempio, un programma di database :-), allora la tua copia sarà un mix di vecchi e nuovi dati, perché i dati non vengono copiati tutti contemporaneamente. Il risultato sarà probabilmente una copia corrotta, motivo per cui in genere non è una buona idea fare copie di database live.

(Detto questo, non ho familiarità con CouchDB ed è possibile progettare un database per resistere a questo tipo di corruzione. Ma è meglio essere assolutamente sicuri.)

— Jander
fonte

Buona spiegazione A proposito, questo mi ha sempre sorpreso perché questo è possibile con sistemi operativi simili a UNIX senza ottenere il tipico messaggio di errore noto da Windows ("Impossibile accedere al file - file in uso") Non è nemmeno possibile riprodurre un file MP3 che è già stato eliminato mentre lo suona. Sotto Unix, puoi (sorprendentemente) - senza alcun problema. Suppongo che i sistemi operativi basati su UNIX funzionino sempre con copie di backup dei file, quindi questo è fattibile.

— syntaxerror,

1

In realtà, essere in grado di leggere un file eliminato proviene da una diversa funzionalità UNIX: in UNIX, file e nomi di file sono cose diverse. Quando si elimina un file, ciò che si sta realmente facendo è l'eliminazione di un "collegamento" denominato nel file. Quando un programma apre un file, anche questo conta come un collegamento. Il sistema eliminerà il file stesso solo quando non ha più collegamenti.

— Jander,

Quindi se il file cresce più velocemente di quanto possiamo copiarlo, cp non terminerà mai? Mi rendo conto che è improbabile, dal momento che qualunque scrittura sul file dovrebbe essere in grado di scrivere sul file, più velocemente di quanto cp possa leggere da esso.

— Bladt