Mam (no cóż, miałem ) katalog:
/media/admin/my_data
Miał rozmiar około 49 GB i zawierał dziesiątki tysięcy plików. Katalog jest punktem podłączenia aktywnej partycji LUKS.
Chciałem zmienić nazwę katalogu na:
/media/admin/my_data_on_60GB_partition
Nie zdawałem sobie wtedy sprawy, ale wydałem polecenie z katalogu domowego, więc skończyłem na:
~% sudo mv /media/admin/my_data my_data_on_60GB_partition
Tak więc mv
program zaczął się przenosić /media/admin/my_data
i jego zawartość do nowego katalogu ~/my_data_on_60GB_partition
.
Użyłem Ctrl+, Caby częściowo anulować polecenie, więc teraz mam całą grupę plików podzielonych na katalogi:
~/my_data_on_60GB_partition <--- about 2GB worth files in here
i
/media/admin/my_data <---- about 47GB of orig files in here
Nowy katalog ~/my_data_on_60GB_partition
i niektóre z jego podkatalogów są własnością root.
Zakładam, że mv
program musiał najpierw skopiować pliki jako root, a następnie po przeniesieniu chown
z powrotem je na moje konto użytkownika.
Mam nieco starą kopię zapasową katalogu / partycji.
Moje pytanie brzmi: czy można niezawodnie przywrócić wiązkę plików, które zostały przeniesione?
Czy mogę po prostu uruchomić:
sudo mv ~/my_data_on_60GB_partition/* /media/admin/my_data
czy powinienem zrezygnować z próby odzyskania, ponieważ pliki są prawdopodobnie uszkodzone i częściowo kompletne itp.?
- System operacyjny - Ubuntu 16.04
mv --version
mv (GNU coreutils) 8.25
źródło
Control-Z
(aby zatrzymać) zamiastControl-C
. W takim przypadku będzie można zobaczyć, który plik został w tym czasie przesłany, a więc wiedzieć, który plik został skopiowany tylko częściowo. Następnie możesz spokojnie zdecydować, jak postępować. (Użyjkill -stop
dla procesów spoza tty).(2GB + 47GB) < 60GB
. pojemność partycji wynosi 60 GB, rozmiar folderu i jego zawartość: 49 GB.Odpowiedzi:
Podczas przenoszenia plików pomiędzy systemami plików,
mv
nie usunąć plik przed jego zakończeniu kopiowania go i przetwarza pliki sekwencyjnie (I początkowo powiedział, że kopie następnie kasuje każdy plik po kolei, ale to nie jest gwarantowane - przynajmniej GNUmv
kopii następnie usuwa każdy Command argument linii , a POSIX określa to zachowanie ). Powinieneś mieć co najwyżej jeden niekompletny plik w katalogu docelowym, a oryginał nadal będzie w katalogu źródłowym.Aby cofnąć zmiany, dodaj
-i
flagę, abymv
niczego nie nadpisywać:(zakładając, że nie masz żadnych ukrytych plików do przywrócenia
~/my_data_on_60GB_partition/
) lub jeszcze lepiej (biorąc pod uwagę, że, jak odkryłeś, możesz mieć wiele plików oczekujących na usunięcie), dodaj-n
flagę, abymv
niczego nie zastępować, ale nie zapytam cię o to:Możesz także dodać
-v
flagę, aby zobaczyć, co się dzieje.W przypadku dowolnej zgodnej z POSIX
mv
oryginalna struktura katalogów powinna pozostać nienaruszona, więc alternatywnie możesz to sprawdzić - i po prostu usunąć/media/admin/my_data
... (W ogólnym przypadku jednak uważam, żemv -n
wariant jest bezpieczny - obsługuje wszystkie formymv
, w tym npmv /media/admin/my_data/* my_data_on_60GB_partition/
.)Prawdopodobnie będziesz musiał przywrócić niektóre uprawnienia; możesz to zrobić masowo za pomocą
chown
ichmod
, lub przywrócić je z kopii zapasowych za pomocągetfacl
isetfacl
(dzięki Sato Katsura za przypomnienie ).źródło
find
aby znaleźć i ustawić uprawnienia. W nowym katalogu jest dużo plików, które mają spacje w nazwach plików, ale nie ma ukrytych plików - o których wiem. Czy uważasz, że glob w poleceniusudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/
rozszerzyłby nazwę pliku bez problemów z podziałem słów? Zastanawiałem się, czy mogę użyć alternatywniesudo rsync ~/my_data_on_60GB_partition/ /media/admin/my_data/
ścieżek plików ze spacjami?rsync
zamiast tego, więc sprawdzałby również integralność wszystkich plików. Ale miło jest wiedzieć, że nie potrzebuję tego.su command mv -i ...
(lubsu /bin/mv -i ...
) zamiastsudo mv -i ...
, na wypadek, gdyby jakiś (dziwny) administrator uczynił „mv” funkcją, która wykonuje „mv -f” na poziomie systemu (tj. / Etc / profile lub podobne pliki systemowe). , polecenie coś: uruchom polecenie coś, a nie funkcję lub alias o tej samej nazwie. (na przykład: można mieć (bardzo!) pecha i mieć (bardzo, bardzo źle!)function mv { /bin/mv -f -- "$@" }
w pliku, który jest zawsze pozyskiwany, a wtedy „rm -i coś” nic nie zapyta (i po prostu zaprotestuje przeciwko „-i „plik nie istnieje!) ... [Widzę takie rzeczy… dreszcz ]Po uzyskaniu odpowiedzi Stephena Kitta i omówieniu tego polecenia jako potencjalnego rozwiązania:
Postanowiłem wstrzymać się z uruchomieniem go, dopóki nie skupię się na tym, co się dzieje, ta odpowiedź opisuje to, czego się dowiedziałam i co skończyłam.
Używam GNU,
mv
który kopiuje pliki do celu, a tylko wtedy, gdy operacja kopiowania się powiedzie, usuwa oryginał.Chciałem jednak potwierdzić, czy
mv
wykonuje tę sekwencję jeden plik na raz, jeśli to prawda, oryginalna zawartość folderu zostałaby czysto podzielona na dwie części, jedna przesunięta do miejsca docelowego, a druga pozostawiona w źródle. Być może miałby miejsce jeden plik, który został przerwany podczas kopiowania, który byłby wspólny dla obu katalogów - i prawdopodobnie byłby zniekształcony.Aby odkryć pliki, które były wspólne między dwoma katalogami, uruchomiłem:
Ten wynik sugerował, że w katalogach źródłowym i docelowym było 14 237 takich samych plików, co potwierdziłem, sprawdzając pliki ręcznie - tak, w obu katalogach było wiele takich samych plików. Sugeruje to, że dopiero po
mv
skopiowaniu wielkich kawałków plików wykonuje usuwanie plików źródłowych. Szybkie wyszukiwanie winfo
namv
komendzie wykazałoNie uruchomiłem polecenia, ale podejrzewam, czy spróbowałem uruchomić
-i
Szybka przed zastąpienie prawdopodobnie byłby uruchamiany ponad 14.000 razy.Następnie sprawdź, ile wszystkich plików w nowo utworzonym katalogu:
Zatem jeśli w nowym katalogu było 14238 zwykłych plików, a 14237 miało identyczne oryginały z powrotem w źródle, oznacza to, że w nowym katalogu był tylko jeden plik, który nie miał odpowiadającego identycznego pliku z powrotem w źródle. Aby dowiedzieć się, co to był plik, uruchomiłem rsync z powrotem w kierunku źródła:
Szybka kontrola potwierdziła, że był to zniekształcony plik, w którym plik istniał zarówno na źródłowym, jak i docelowym, docelowym pliku = 64 MB, oryginalnym = 100 MB. Ten plik i jego hierarchia katalogów były nadal własnością roota i nie przywrócono jeszcze oryginalnych uprawnień.
Podsumowując:
mv
nigdy nie dotarły, wciąż znajdują się w swoich oryginalnych lokalizacjach (oczywiście)mv
całkowicie skopiowane, nadal miały swoje oryginalne kopie w katalogu źródłowymInnymi słowy wszystkie oryginalne pliki pozostały nienaruszone, a rozwiązaniem w tym przypadku było po prostu usunięcie nowego katalogu!
źródło
-n
byłoby lepiej w ogólnym przypadku. Sprawdziłemmv
kod źródłowy, usuwa on jeden argument naraz.mv
usuwa się źródło. Więc poleceniemv foo bar baz
przejdziefoo
do,baz/foo
a następnie usunie oryginał,foo
a następniebar
dobaz/bar
...?cmp
zamiastdiff
porównywać pliki binarne. Ponadto powyższa dyskusja ma sens tylko podczas przenoszenia plików między różnymi systemami plików. Przenoszenie plików w tym samym systemie plików nie wymaga kopiowania.Pomyślałem, że skomentuję, że niektórzy ludzie mogą mieć ochotę wrzucić „xargs” do miksu, aby równolegle uruchamiać rzeczy. To daje mi wolę i naprawdę podoba mi się powyższe rozwiązanie rsync.
Jeśli chodzi o system plików o przenoszeniu i kopiowaniu oraz o tym, kiedy dokładnie zostanie usunięty oryginał, VFS i bazowy system (pliki) współrzędnych gwarantują atomowość poszczególnych plików przed przejściem do tego kroku usuwania. Więc nawet jeśli zostanie przerwany przed pełnym zapisaniem pliku docelowego, całe blokowanie w VFS jest naprawdę ścisłe i chroni przed takimi przypadkowymi przeplataniem danych, nawet w równoległych przypadkach. (Pracowałem na Linux VFS i NFS4)
Dodanie „xargs” do miksu prawdopodobnie sprawiłoby, że krok sprawdzania podwójnego zdrowia byłby kłopotliwy, z wieloma plikami w połowie tranzytu. Chciałbym mieć więcej skryptów na poziomie systemu. Dobre przypomnienia dla mnie!
Podobało mi się pytanie, dobre dla pajęczyn i sprawia, że znów kocham rsync. Twoje zdrowie!
źródło