Was passiert bei Linux, wenn man mit "mv" einen Ordner auf ein Laufwerk mit zu wenig Platz verschiebt?
-
In dem Ordner seien 100 Dateien und der Gesamtspeicherbedarf größer, als auf dem Zielmedium vorhanden ist.
Was passiert in diesem Moment also?
Soviel ist schonmal sicher, der mv Befehlt wird einen Teil der Dateien auf das Laufwerk kopieren, bis es voll ist und dann bricht der mv Befehl mit einer Fehlermeldung ab.Aber was passiert genau in dem moment des Abbruchs mit der Datei, die in genau diesem Moment verschoben wird?
A) Wird sie nur zum Teil auf das neue Medium kopiert und auf dem Quellmedium gelöscht?
Bleibt ein Teil der Datei auf dem Zielmedium erhalten und aber auch die ganze Datei auch auf dem Quellmedium?
C) Die Verschiebung wird auf dem Zielmedium rückgängig gemacht und die Datei bleibt auf dem Quellmedium erhaltenKurz gesagt, ist der mv Befehl atomar?
Und wenn nun ein Ordner mit sagen wir mal 10 Dateien verschoben wird und bei der 5. Datei bricht mv wegen Speichermangel das verschieben ab,
hat man dann:A) Ein Quellordner so wie er vor dem mv Befehl war?
Ein Quellordner in dem nur noch ein kleiner Teil an Dateien vorhanden ist, während alle anderen auf dem Zielmedium sind?Die letzte Frage wäre also.
Wenn der Ordner nun auf den beiden Medien zerissen ist, wie führt man ihn dann am besten wieder zusammen, so daß er logisch einen Ordner wie im Ursprungszustand bildet?
Sollte man einfach alles was im Zielordner ist auf den Quellordner mit mv zurückschieben?
Wenn ja, überschreibt man dann nicht alles, was auf dem Quellordner ist?
-
Zur letzten Frage noch:
Was ist, wenn das Zielmedium ein FAT32 Dateisystem ist und somit keine Groß und kleinschreibung kennt?
Dann überschreibt man beim zurückschieben doch sicher einige Dateien, wenn diese die gleichen Buchstabenfolgen nur halt mit unterscheidlicher Groß und KLeinschreibung haben?
Wie führt man also in diesem Fall die beiden Ordner wieder zu einem zusammen?
-
Problemfrage schrieb:
Was ist, wenn das Zielmedium ein FAT32 Dateisystem ist und somit keine Groß und kleinschreibung kennt?
Falls es um Backups geht, würde ich zu rdiff-backup raten. Das kümmert sich (fast immer) um genau solche Probleme.
-
Christoph schrieb:
Problemfrage schrieb:
Was ist, wenn das Zielmedium ein FAT32 Dateisystem ist und somit keine Groß und kleinschreibung kennt?
Falls es um Backups geht, würde ich zu rdiff-backup raten. Das kümmert sich (fast immer) um genau solche Probleme.
Nein, ich bezog mich hier jetzt schon rein auf den mv Befehl.
-
Problemfrage schrieb:
A) Wird sie nur zum Teil auf das neue Medium kopiert und auf dem Quellmedium gelöscht?
Bleibt ein Teil der Datei auf dem Zielmedium erhalten und aber auch die ganze Datei auch auf dem Quellmedium?
C) Die Verschiebung wird auf dem Zielmedium rückgängig gemacht und die Datei bleibt auf dem Quellmedium erhaltenBei mv wird erst die Datei kopiert und nur bei Erfolg die alte gelöscht. Also fällt A) schonmal raus. Bei den anderen beiden bin ich mir nicht ganz sicher, meine aber das die zum Teil kopierte Datei erhalten bleibt. Also B).
Problemfrage schrieb:
Und wenn nun ein Ordner mit sagen wir mal 10 Dateien verschoben wird und bei der 5. Datei bricht mv wegen Speichermangel das verschieben ab,
hat man dann:A) Ein Quellordner so wie er vor dem mv Befehl war?
Ein Quellordner in dem nur noch ein kleiner Teil an Dateien vorhanden ist, während alle anderen auf dem Zielmedium sind?Soweit ich gelesen habe werden Ordner immer erst komplett kopiert. Das heißt mv löscht die Quelldateien erst wenn der Ordner komplett abgearbeitet ist. Also A).
Problemfrage schrieb:
Die letzte Frage wäre also.
Wenn der Ordner nun auf den beiden Medien zerissen ist, wie führt man ihn dann am besten wieder zusammen, so daß er logisch einen Ordner wie im Ursprungszustand bildet?
Sollte man einfach alles was im Zielordner ist auf den Quellordner mit mv zurückschieben?
Wenn ja, überschreibt man dann nicht alles, was auf dem Quellordner ist?Einfach nochmal von Quelle -> Ziel verschieben und dabei evtl. vorhandene Dateien überschreiben. Das Ziel hat ja schon einige kompletten Dateien und (nur) diejenigen die kaputt sind werden dann durch die kompletten überschrieben.
-
Hat das inzwischen jemand getestet?
-
man mv verweist auf info coreutils 'mv invocation':
It first uses some of the same code that's used by `cp -a'
to copy the requested directories and files, then (assuming the copy
succeeded) it removes the originals. If the copy fails, then the part
that was copied to the destination partition is removed.
[...]
If you were
to copy three directories from one partition to another and the copy of
the first directory succeeded, but the second didn't, the first would
be left on the destination partition and the second and third would be
left on the original partition.Kurz: RTFM
-
Danke, aber was genau passiert mit einzelnen Dateien?
-
directories and files
-
Es kommt auch auf die Implementation von mv an. Bei Debian Woody hat mv folgendes gemacht: Kopiert man Daten die größer als der freie Plattenplatz der ext3 Partition hat mv einfach auf die anderen dort bereits vorhandenen Dateien daraufgeschrieben, so dass am Ende viele Dateien beschädigt sind. Es wird dann 0 Bytes freier Platz angezeigt. (Kann auch daran liegen das ich bei der Erstellung der Partition diesen 5% Root Freiplatz auf 0 gesetzt habe.)
Ist mir mal mit meiner Avi Sammlung geschehen. Bei den Avis konnte man auf einmal nicht mehr vor und und zurück navigieren und mitten drin ist der Player ausgestiegen.
-
--------- schrieb:
Es kommt auch auf die Implementation von mv an. Bei Debian Woody hat mv folgendes gemacht: Kopiert man Daten die größer als der freie Plattenplatz der ext3 Partition hat mv einfach auf die anderen dort bereits vorhandenen Dateien daraufgeschrieben, so dass am Ende viele Dateien beschädigt sind.
Das halte ich doch für äußerst unwahrscheinlich, weil das ja ein schwerwiegender Bug im Dateisystem wäre. Gibt es dazu eine passende Bugmeldung?