Das ist ihnen nicht garantiert. Es ist möglich, dass /foo/oldPath ist ein Einhängepunkt.
Dies kann jedoch leicht durch Ausführen von mount | grep 'on /foo/oldPath' überprüft werden Keine Ausgabe sollte darauf hinweisen, dass oldPath Verzeichnis ist kein Einhängepunkt.
Sie müssen vorsichtiger sein, wenn Sie verschachtelte Verzeichnisse verwenden, da Sie überall einen Einhängepunkt haben können.
Ich bin mir nicht sicher, ob dies automatisiert ist, aber es ist erwähnenswert, dass das 3. Feld von mount (durch Leerzeichen getrennt) der Mount-Punkt für jede Zeile ist, also einen cut -d ' ' -f 3 verwendet könnte verwendet werden, um den Pfad zu extrahieren (falls Sie sicherstellen müssen, dass es sich nicht nur um eine Teilzeichenfolge eines anderen Einhängepunkts handelt, wie /foo/oldPath/nested/mountPoint )
Wenn Sie dies in C/C++-Code übersetzen möchten, können Sie möglicherweise system("mount | grep 'on /foo/oldPath'") verwenden , aber darauf schwöre ich nicht. Möglicherweise haben Sie bei StackOverflow mehr Glück, wenn Sie dort weitere Implementierungsdetails benötigen.
Sie sollten dies aus verschiedenen Gründen (ausführlich in den anderen Antworten) nicht versuchen:/foo/oldPath könnte selbst ein Einhängepunkt sein, oder ein Overlay-Dateisystem könnte vorhanden sein und das Verschieben von Dateien verhindern. Sie können sogar Bind-Mounts bei einzelnen Dateien feststellen, was ebenfalls Probleme beim Umbenennen von Dateien verursacht.
Anstatt zu versuchen, im Voraus festzustellen, ob die Dateien umbenannt werden können, sollten Sie versuchen, sie umzubenennen und die Fehler zu beheben. rename gibt -1 zurück, wenn ein Fehler auftritt, und errno wird auf EXDEV gesetzt wenn die Umbenennung aufgrund von Cross-Mount-Problemen nicht möglich ist. Sie können dann auf andere Weise fortfahren (kopieren und löschen).
Um festzustellen, ob sich zwei Dateisystemobjekte auf demselben Dateisystem befinden, sollten Sie im Allgemeinen stat ausführen darauf und sehen Sie sich die Gerätekennung an (die st_dev Feld in struct stat ). Zwei Dateisystemobjekte auf demselben Dateisystem haben dieselbe Gerätekennung.
Beachten Sie, dass Sie sich bei der Ausführung auf Overlayfs nicht auf rename() verlassen können von bereits bestehenden Verzeichnissen.
Ich denke, Sie könnten diese Möglichkeit normalerweise ignorieren, wenn Sie kein Allzweck-Dateiverwaltungstool schreiben ... Zum Beispiel einen Paketmanager ... in diesem Fall halten Sie es anscheinend nicht für reparierbar (aus Gründen der Atomizität) und wollen es auf den neuen redirect_dir zu verlassen Format von Overlayfs.
Das ist also eher eine pedantische Anmerkung, um Sie wissen zu lassen, dass dies Linux ist, wir POSIX nicht einhalten, wenn wir es nicht wollen, und "garantiert" ist ein sehr starkes Wort :).
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
Wenn die Funktion "redirect_dir" nicht aktiviert ist, schlägt rename(2) in einem niedrigeren oder zusammengeführten Verzeichnis mit EXDEV fehl.
Overlayfs entspricht bereits in anderen Details nicht den üblichen Erwartungen an ein Unix-Dateisystem:
Objekte, die keine Verzeichnisse sind (Dateien, symbolische Links, gerätespezifische Dateien usw.), werden je nach Bedarf entweder aus dem oberen oder unteren Dateisystem dargestellt. Wenn auf eine Datei im unteren Dateisystem auf eine Weise zugegriffen wird, die einen Schreibzugriff erfordert, wie z. B. das Öffnen für den Schreibzugriff, das Ändern einiger Metadaten usw., wird die Datei zuerst vom unteren Dateisystem in das obere Dateisystem kopiert (copy_up) ...
Die copy_up-Operation erstellt im Wesentlichen eine neue, identische Datei und verschiebt sie auf den alten Namen. Alle geöffneten Dateien, die auf diesen Inode verweisen, greifen auf die alten Daten zu.