☰

Atomare Entfernung eines Verzeichnisses

tag-icon • tag-icon linux rename mv concurrency
Atomare Entfernung eines Verzeichnisses

Da rename(2)von aufgerufen wird mv, kann man davon ausgehen, dass das Folgende atomar ist?

$ mv /home/me/someDir /tmp/toBeDeleted
$ rm -rf /tmp/toBeDeleted

Antwort1

DermvBefehlruft dierenameSystemaufruf, das garantiert atomar ist. Es gibt jedoch zwei Ausnahmen:

  • Wenn sich Quelle und Ziel auf unterschiedlichen Dateisystemen befinden, was bei /homevs. relativ häufig vorkommt /tmp, schlägt dies renamefehl und mvfunktioniert dann, indem der Quellbaum in das Ziel kopiert und dann der Quellbaum entfernt wird. Dies ist offensichtlich nicht atomar.
  • Es gibt Dateisysteme, bei denen renamenicht atomar ist, wie z. B. bestimmte Implementierungen von NFS. Auf jedem „normalen“ lokalen Dateisystem renameist atomar.

Antwort2

Wenn sich die Verzeichnisse auf derselben Hardwarepartition befinden, die als einzelnes Dateisystem gemountet ist, dann ist das Verschieben von etwas eigentlich nur das Umbenennen in einen anderen Pfad. Wenn dies jedoch nicht der Fall ist, muss jede darin enthaltene Datei möglicherweise eingelesen und kopiert werden, sodass kein Teil der Verschiebung atomar wäre. Wie Gilles betont, legt POSIX fest, dass dies für diskrete Dateisysteme der Fall ist.

Abgesehen davon verwendet eine schnelle Überprüfung mit strace„confirms“ den Systemaufruf (nicht zu verwechseln mit , dem Befehlszeilenprogramm). Das würde die In-Verzeichnis-Funktion aus Benutzersicht atomar machen. Der Systemaufruf wird einen EBUSY-Fehler ausgeben, wenn:mvrename()renamemvrename()

oldpath oder newpath ist ein Verzeichnis, das von einem Prozess verwendet wird (beispielsweise als aktuelles Arbeitsverzeichnis oder als Stammverzeichnis oder weil es zum Lesen geöffnet war) oder vom System verwendet wird (beispielsweise als Einhängepunkt), während das System dies als Fehler betrachtet. (Beachten Sie, dass in solchen Fällen keine EBUSY zurückgegeben werden muss – es ist nichts falsch daran, die Umbenennung trotzdem durchzuführen –, aber es ist zulässig, EBUSY zurückzugeben, wenn das System solche Situationen nicht anders handhaben kann.)

Von man 2 rename. Die Verbindung zur „Atomarität“ besteht hier darin, dass Sie keinen anderen Prozess unterbrechen können, der im Verzeichnis arbeitet, und ein anderer Prozess diesen nicht unterbrechen kann – es endet mit einem Fehler wegen eines ungültigen Pfads/nicht gefundenen Typs, wenn Sie ihn bei der Jagd überholen.

Antwort3

Beide Antworten sagen im Wesentlichen dasselbe, konzentrieren sich aber nur auf einen Aspekt der Entfernung.

Wenn Sie eine Shell haben, deren Arbeitsverzeichnis sich innerhalb des umbenannten/verschobenen Verzeichnisbaums befindet, wird sie weiterhinsehenUndverwendendiese Dateien, bis sie tatsächlich entfernt werden. Aus diesem Grund sieht die Shell die Dateien in unterschiedlichen Löschzuständen und folglich wird das Umbenennen/Verschieben (während MaiSei"atomar"an sich) istnichteine atomare Form der Löschung aus Sicht aller Benutzer der Dateien. Sie betrifft nur Benutzer, deren Shell von vornherein außerhalb des Verzeichnisbaums liegt.

Die Shell verwaltet ihre eigenen Informationen darüber, in welchem ​​Verzeichnis sie sich befindet. Das liegt daran, dass Sie in einigen Konfigurationen das aktuelle Verzeichnis in ein Verzeichnis ändern können, für das Sie keine Berechtigung zum Lesen der Kette von Verzeichnisinformationen haben, die zur Ermittlung des tatsächlichen Pfads erforderlich ist, z. B. indem Sie einem symbolischen Link in ein geschütztes Verzeichnis folgen.

POSIX ist vage in Bezug auf den Grund für das Verhalten, weist aber auf das Verhalten hin fürpwd(Shell integriert) undcd(Shell integriert).

verwandte Informationen