Gibt es irgendwelche Gefahren bei der Verwendung von mv (anstelle von cp gefolgt von rm)?

Ich bin ein Doktorand mit Zugang zu einem Linux-Cluster einer Forschungsgruppe an meiner Universität. Im Laufe der Jahre habe ich viele Verzeichnisse gesammelt - ich denke, "Ordner" sind Windows / Mac-Terminologie? - in meinem Home-Verzeichnis ( ~). Wenn ich an einer neuen Simulation arbeite, erstelle ich ein neues Verzeichnis in meinem Ausgangsverzeichnis mit mkdirund führe dann die Simulation in diesem Verzeichnis aus.

Aber im Laufe der Zeit habe ich viele solcher Verzeichnisse in meinem Home-Verzeichnis gesammelt. Jetzt möchte ich einige der Verzeichnisse in das Unterverzeichnis verschieben. Beispielsweise möchte ich möglicherweise ein neues Verzeichnis mit dem Namen erstellen simulations1_10und dann die Verzeichnisse simulation1,, simulation2... simulation10in dieses Verzeichnis verschieben, damit das Stammverzeichnis meines Ausgangsverzeichnisses besser organisiert ist.

Dafür könnte ich verwenden cp. Zum Beispiel:

cp -r simulation1/ simulations1_10/

würde das Verzeichnis simulation1(und seinen gesamten Inhalt) in das Verzeichnis kopieren simulations1_10. Ich könnte dann entfernen simulation1.

Aber, meine Transfers sind nicht überqueren Dateisystem Grenzen, so mvist viel schneller als cp. ( mvNatürlich kann ich auch den Schritt zum Entfernen vermeiden.) Zum Beispiel:

mv simulation1/ simulations1_10/

hat schnell den Trick (und im Gegensatz cp, mvist rekursiv Standard). Nach dieser Antwort auf diese Frage , mvist viel schneller , weil es „nur die Inode - Datenbank in verschiedenen Verzeichnissen aktualisiert.“

Meine Frage ist, gibt es irgendwelche Gefahren bei der Verwendung mv?

Ich denke, dass eine Gefahr darin besteht, dass die Datei sowohl in der Quelle als auch im Ziel beschädigt wird, wenn sie während einer Übertragung mvunterbrochen wird (aufgrund eines Stromausfalls, Drücken des Benutzers Ctrl+ Cusw.) . Ist das richtig?

Wenn ich mv viel benutze , besteht dann die Möglichkeit, dass die "Inode-Datenbank" zu oft aktualisiert wird, was zu Festplattenfragmentierung oder anderen Festplatten- / Dateisystemproblemen führt?

Die renameFunktion (das liegt unter dem Befehl mv, „The Utility mv Aktionen ausführen soll äquivalent die Umbenennungs () -Funktion“ ) ist atomar (siehe POSIX http://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html , dass bezieht sich auf den C-Standard):

Diese Funktion zum Umbenennen () entspricht für reguläre Dateien der im ISO C-Standard definierten. Durch die Aufnahme hier wird diese Definition um Aktionen für Verzeichnisse erweitert und das Verhalten angegeben, wenn der neue Parameter eine bereits vorhandene Datei benennt. Diese Spezifikation erfordert, dass die Wirkung der Funktion atomar ist.

(Beachten Sie jedoch die folgenden Vorsichtsmaßnahmen: https://unix.stackexchange.com/a/322074/88983 .)

Unterbrochene Vorgänge, sei es durch Strg-C oder auf andere Weise, sollten niemals zu teilweise übertragenen Dateien führen. Wie Sie bereits erwähnt haben, mvkopiert ein einzelnes Dateisystem tatsächlich keinen Dateiinhalt, sondern nur Dateimetadaten. Das Schlimmste, was an dieser Front passieren sollte, ist, teilweise verschobene Verzeichnisse zu sehen (wenn Sie dies tun mv a b c dest, ist es möglich, zu unterbrechen und nur zB azu verschieben dest, aber alle Dateien und deren Inhalte wurden ordnungsgemäß verschoben), nicht teilweise verschoben Dateien.

Zu Ihrer Inode-Nebenfrage würde ich sagen, dass dies im Allgemeinen kein Problem darstellt. Das Aktualisieren von Inodes, um nur wenige Verzeichnisse zu verschieben, ist eine Routineoperation mit geringem Overhead (Schreibvorgänge für Dateiinhalte, die auf demselben Dateisystem ausgeführt werden, sollten je nach Dateisystemtyp einen viel größeren potenziellen Leistungseinbruch oder eine Fragmentierungsursache darstellen).