Co się stanie, jeśli plik zostanie zmodyfikowany podczas kopiowania?

19

Jaki jest efekt kopiowania pliku, powiedz fileA.big (900mb) z lokalizacji B do lokalizacji C. Jeśli podczas tej operacji cp powiedzmy 35% przez proces, do plikuA.big dołączone zostaną nowe informacje i wzrośnie z 900 MB do 930 MB.

Jaki jest wynik kopii końcowej (tj. FileA.big at locationC)?

Co się stanie, jeśli kopia ma w przybliżeniu 70%, a oryginalny plik jest aktualizowany, ale tym razem obcięty do 400 MB (tj. Postęp kopiowania jest poza punktem obcięcia), jaki jest wynik kopii końcowej?

Odwoływanie się do systemu operacyjnego Linux w systemie plików ext3 / ext4. Brak magii cienia głośności itp. Po prostu stary cp. Ciekawość wywołana przez kopiowanie plików couchdb na żywo do tworzenia kopii zapasowych, ale bardziej zainteresowani ogólnymi scenariuszami niż konkretnym przypadkiem użycia.

cp file-copy

— Mâtt Frëëman
źródło

Dziękuję za pytanie. Moja „wiedza” była w większości przypuszczeniem… aż do teraz.

— tshepang

10

Jeśli fileA.bigjest uprawiany podczas kopiowania, kopia będzie zawierać dane, które zostały dołączone.

Jeśli plik zostanie obcięty krócej niż miejsce, w którym aktualnie znajduje się kopia, kopia zostanie przerwana dokładnie tam, gdzie jest, a plik docelowy będzie zawierał to, co zostało skopiowane do momentu przerwania.

— Patrick
źródło

27

Patrick ma mniej więcej rację, ale oto dlaczego. Sposób kopiowania pliku w systemie UNIX działa w następujący sposób:

Spróbuj odczytać (więcej) bajtów z fileA.
Jeśli nie udało nam się pobrać bajtów, ponieważ jesteśmy na (lub w przeszłości) na końcu pliku, jesteśmy skończeni; porzucić.
W przeciwnym razie zapisz bajty fileBi powróć do kroku 1.

Wiedząc o tym i wiedząc, że to takie proste, możemy zobaczyć niektóre narożne przypadki.

Gdy tylko znajdziemy koniec pliku, kopiowanie jest gotowe. Powiedzmy, że nasz plik rośnie podczas kopiowania, ale rośnie wolniej niż my go kopiujemy. Program kopiujący będzie nadal przekraczał pierwotny rozmiar pliku, ponieważ zanim się tam dostanie, plik zawiera więcej. Ale w pewnym momencie, że dogania koniec pliku, a ona wie, że to w końcu dlatego, że nie potrafi czytać więcej bajtów teraz . Tak więc kończy pracę, nawet jeśli plik ma się dalej powiększać.

Jeśli plik jest obcięty, program kopiujący mówi „Whoa, jestem za końcem pliku!” i odchodzi.

A jeśli fragmenty pliku są aktualizowane losowo przez, powiedzmy, program bazy danych :-), to twoja kopia będzie mieszanką starych i nowych danych, ponieważ nie wszystkie dane są kopiowane w tym samym czasie. Rezultatem będzie prawdopodobnie uszkodzona kopia, dlatego generalnie nie jest dobrym pomysłem tworzenie kopii żywych baz danych.

(To powiedziawszy, nie znam CouchDB i możliwe jest zaprojektowanie bazy danych, która będzie odporna na tego rodzaju uszkodzenia. Ale najlepiej mieć absolutną pewność.)

— Jander
źródło

Dobre wytłumaczenie. Przy okazji, zawsze mnie zaskakiwało, dlaczego jest to możliwe w systemach operacyjnych typu UNIX bez uzyskania typowego komunikatu o błędzie znanego z systemu Windows („Nie można uzyskać dostępu do pliku - plik w użyciu”). Nie można nawet odtworzyć pliku MP3, który został już usunięty podczas grania. W Unixie możesz (zaskakująco) - bez żadnych problemów. Wydaje mi się, że systemy operacyjne oparte na UNIX zawsze działają z kopiami zapasowymi plików, więc jest to możliwe.

— syntaxerror

1

W rzeczywistości możliwość odczytu usuniętego pliku pochodzi z innej funkcji UNIX: w systemie UNIX pliki i nazwy plików są różne. Kiedy usuwasz plik, tak naprawdę robisz to usunięcie nazwanego „linku” do pliku. Gdy program otwiera plik, jest to również liczone jako łącze. System usunie sam plik tylko wtedy, gdy nie pozostaną mu żadne łącza.

— Jander

Więc jeśli plik rośnie szybciej niż możemy go skopiować, cp nigdy się nie zakończy? Zdaję sobie sprawę, że jest to mało prawdopodobne, ponieważ wszystko, co zapisuje się w pliku, musiałoby mieć możliwość zapisu do pliku, szybciej niż cp może z niego odczytać.

— Bladt,