.\" -*- coding: UTF-8 -*- .\" This manpage is Copyright (C) 1992 Drew Eckhardt; .\" and Copyright (C) 1993 Michael Haardt; .\" and Copyright (C) 1993,1995 Ian Jackson .\" and Copyright (C) 2006, 2014 Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" Modified Sat Jul 24 00:35:52 1993 by Rik Faith .\" Modified Thu Jun 4 12:21:13 1998 by Andries Brouwer .\" Modified Thu Mar 3 09:49:35 2005 by Michael Haardt .\" 2007-03-25, mtk, added various text to DESCRIPTION. .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH rename 2 "5. Februar 2023" "Linux man\-pages 6.03" .SH BEZEICHNUNG rename, renameat, renameat2 \- den Namen oder die Lage einer Datei ändern .SH BIBLIOTHEK Standard\-C\-Bibliothek (\fIlibc\fP, \fI\-lc\fP) .SH ÜBERSICHT .nf \fB#include \fP .PP \fBint rename(const char *\fP\fIalterpfad\fP\fB, const char *\fP\fIneuerpfad\fP\fB);\fP .PP \fB#include \fP/* Definition der \fBAT_*\fP\-Konstanten */ \fB#include \fP .PP \fBint renameat(int \fP\fIaltVerzdd\fP\fB, const char *\fP\fIalterpfad\fP\fB,\fP \fB int \fP\fIneuVerzdd\fP\fB, const char *\fP\fIneuerpfad\fP\fB);\fP \fBint renameat2(int \fP\fIaltVerzdd\fP\fB, const char *\fP\fIalterpfad\fP\fB,\fP \fB int \fP\fIneuVerzdd\fP\fB, const char *\fP\fIneuerpfad\fP\fB, unsigned int \fP\fISchalter\fP\fB);\fP .fi .PP .RS -4 Mit Glibc erforderliche Feature\-Test\-Makros (siehe \fBfeature_test_macros\fP(7)): .RE .PP .nf \fBrenameat\fP(): Seit Glibc 2.10: _POSIX_C_SOURCE >= 200809L Vor Glibc 2.10: _ATFILE_SOURCE .PP \fBrenameat2\fP(): _GNU_SOURCE .fi .SH BESCHREIBUNG \fBrename\fP() benennt eine Datei um und verschiebt sie in ein anderes Verzeichnis, wenn nötig. Alle anderen Hardlinks (erstellt mittels \fBlink\fP(2)) sind nicht betroffen, ebenso offene Dateideskriptoren für \fIalterpfad\fP. .PP Verschiedene Einschränkungen bestimmen, ob die Umbenennungsaktion erfolgreich ist oder nicht; siehe FEHLER unten. .PP Falls \fIneuerpfad\fP schon existiert, wird er in einem atomaren Schritt überschrieben, so dass ein anderer Prozess jederzeit auf \fIneuerpfad\fP zugreifen kann. Allerdings wird es wahrscheinlich ein Fenster geben, in dem sowohl \fIalterpfad\fP als auch \fIneuerpfad\fP sich auf die umzubenennende Datei beziehen. .PP Falls \fIalterpfad\fP und \fIneuerpfad\fP bestehende Hardlinks zu derselben Datei sind, tut \fBrename\fP() nichts und meldet eine erfolgreiche Ausführung. .PP Wenn \fIneuerpfad\fP schon existiert, aber das Umbenennen aus irgendeinem Grund fehlschlägt, garantiert \fBrename\fP(), dass \fIneuerpfad\fP an Ort und Stelle erhalten bleibt. .PP \fIalterpfad\fP kann ein Verzeichnis angeben. In diesem Fall darf \fIneuerpfad\fP nicht existieren oder muss ein leeres Verzeichnis angeben. .PP Falls \fIalterpfad\fP auf einen symbolischen Link zeigt, wird der Link umbenannt; falls \fIneuerpfad\fP auf einen symbolischen Link zeigt, wird der Link überschrieben. .SS renameat() Der Systemaufruf \fBrenameat\fP() funktioniert genauso wie \fBrename\fP(), außer den hier beschriebenen Unterschieden. .PP Falls der in \fIalterpfad\fP übergebene Pfadname relativ ist wird er als relativ zu dem im Dateideskriptor \fIaltVerzdd\fP referenzierten Verzeichnis interpretiert (statt relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei \fBrename\fP() für einen relativen Pfadnamen erfolgt). .PP Falls \fIalterpfad\fP relativ ist und \fIaltVerzdd\fP den besonderen Wert \fBAT_FDCWD\fP annimmt wird \fIalterpfad\fP als relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie \fBrename\fP()). .PP Falls \fIalterpfad\fP absolut ist wird \fIaltVerzdd\fP ignoriert. .PP Die Interpretation von \fIneuerpfad\fP ist wie bei \fIalterpfad\fP, außer dass ein relativer Pfadname als relativ zu dem Verzeichnis interpretiert wird, auf das der Dateideskriptor \fIneuVerzdd\fP verweist. .PP Lesen Sie \fBopenat\fP(2) für eine Beschreibung der Notwendigkeit von \fBrenameat\fP(). .SS renameat2() \fBrenameat2\fP() hat ein zusätzliches Argument \fISchalter\fP. Ein Aufruf von \fBrenameat2\fP() mit einem leeren Argument \fISchalter\fP ist äquivalent zu \fBrenameat\fP(). .PP Das Argument \fISchalter\fP ist eine Bitmaske, die aus null oder mehr der folgenden Schalter besteht: .TP \fBRENAME_EXCHANGE\fP tauscht \fIalterpfad\fP und \fIneuerpfad\fP atomisch aus. Beide Pfadnamen müssen existieren, können aber verschiedenen Typs sein. Beispielsweise kann ein Pfad ein nicht\-leeres Verzeichnis und der andere ein symbolischer Link sein. .TP \fBRENAME_NOREPLACE\fP überschreibt \fIneuerpfad\fP beim Umbenennen nicht. Ein Fehler wird zurückgegeben, wenn \fIneuerpfad\fP bereits existiert. .IP \fBRENAME_NOREPLACE\fP kann nicht zusammen mit \fBRENAME_EXCHANGE\fP eingesetzt werden. .IP \fBRENAME_NOREPLACE\fP benötigt Unterstützung vom zugrundeliegenden Dateisystem. Die Unterstützung für verschiedene Dateisysteme wurde wie folgt hinzugefügt: .RS .IP \[bu] 3 .\" ext4: commit 0a7c3937a1f23f8cb5fc77ae01661e9968a51d0c Ext4 (Linux 3.15); .IP \[bu] Btrfs, Tmpfs und Cifs (Linux 3.17); .IP \[bu] .\" btrfs: commit 80ace85c915d0f41016f82917218997b72431258 .\" tmpfs: commit 3b69ff51d087d265aa4af3a532fc4f20bf33e718 .\" cifs: commit 7c33d5972ce382bcc506d16235f1e9b7d22cbef8 .\" .\" gfs2 in Linux 4.2? XFS (Linux 4.0); .IP \[bu] .\" Also affs, bfs, exofs, hfs, hfsplus, jffs2, logfs, msdos, .\" nilfs2, omfs, sysvfs, ubifs, udf, ufs .\" hugetlbfs, ramfs .\" local filesystems: commit f03b8ad8d38634d13e802165cc15917481b47835 .\" libfs: commit e0e0be8a835520e2f7c89f214dfda570922a1b90 Die Unterstützung für viele andere Dateisysteme wurde in Linux 4.9 hinzugefügt, einschließlich Ext2, Minix, Reiserfs, Jfs, Vfat und Bpf. .RE .TP \fBRENAME_WHITEOUT\fP (seit Linux 3.18) .\" commit 0d7a855526dd672e114aff2ac22b60fc6f155b08 .\" commit 787fb6bc9682ec7c05fb5d9561b57100fbc1cc41 Diese Aktion ergibt nur für Implementierungen von Overlay/Union\-Dateisystemen Sinn. .IP Durch Angabe von \fBRENAME_WHITEOUT\fP wird ein »whiteout«\-Objekt bei der Quelle der Umbenennung zum gleichen Zeitpunkt der Durchführung der Umbenennung erzeugt. Die gesamte Aktion ist atomar, so dass der Whiteout erstellt sein wird, wenn die Umbenennung erfolgreich war. .IP Ein »Whiteout« ist ein Objekt, das in Union/Overlay\-Dateisystemkonstrukten eine besondere Bedeutung hat. In diesen Konstrukten existieren mehrere Ebenen, wobei jedoch nur die oberste Ebene jemals verändert wird. Ein »Whiteout« in einer der oberen Ebenen versteckt eine entsprechende Datei in der unteren Ebene, wodurch es so aussieht, als würde die Datei nicht existieren. .IP Wenn eine Datei auf einer unteren Ebene umbenannt wird, wird die Datei zuerst hochkopiert (falls sie nicht bereits auf der oberen Ebene ist) und dann auf der oberen, lese\-schreibbaren Ebene umbenannt. Gleichzeitig muss die Quelldatei »whiteouted« werden (so dass die Version der Quelldatei in der unteren Ebene unsichtbar gemacht wird). Die gesamte Aktion muss atomar sein. .IP .\" https://www.freebsd.org/cgi/man.cgi?query=mount_unionfs&manpath=FreeBSD+11.0-RELEASE Wenn es nicht Teil eines Union/Overlay\-Dateisystems ist, dann erscheint ein »Whiteout« als zeichenorientiertes Gerät mit einer Gerätenummer {0,0}. Beachten Sie, dass andere Union/Overlay\-Implementierungen anders mit der Speicherung von »Whiteout«\-Einträgen umgehen könnten. Insbesondere verwendet »Union mount« auf BSD\-Systemen einen separaten Inode\-Typ \fBDT_WHT\fP. Dieser wird – zumindest in Linux 4.19 – vom »Whiteout«\-Support\-Code des Kernels ignoriert, obwohl er von einigen unter Linux verfügbaren Dateisystemen, wie CODA und XFS, dennoch unterstützt wird .IP \fBRENAME_WHITEOUT\fP benötigt die gleichen Privilegien wie zum Erstellen eines Geräteknotens (d.h. die Capability \fBCAP_MKNOD\fP). .IP \fBRENAME_WHITEOUT\fP kann nicht zusammen mit \fBRENAME_EXCHANGE\fP eingesetzt werden. .IP .\" tmpfs: commit 46fdb794e3f52ef18b859ebc92f0a9d7db21c5df .\" ext4: commit cd808deced431b66b5fa4e5c193cb7ec0059eaff .\" XFS: commit 7dcf5c3e4527cfa2807567b00387cf2ed5e07f00 .\" f2fs: commit 7e01e7ad746bc8198a8b46163ddc73a1c7d22339 .\" btrfs: commit cdd1fedf8261cd7a73c0596298902ff4f0f04492 .\" ubifs: commit 9e0a1fff8db56eaaebb74b4a3ef65f86811c4798 \fBRENAME_WHITEOUT\fP benötigt die Unterstützung vom darunterliegenden Dateisystem. Unter den Dateisystemen, die die Unterstützung anbieten, sind Tmpfs (seit Linux 3.18), Ext4 (seit Linux 3.18), XFS (seit Linux 4.1), F2fs (seit Linux 4.2), Btrfs (seit Linux 4.7) und Ubifs (seit Linux 4.9). .SH RÜCKGABEWERT Bei Erfolg wird Null zurückgegeben. Bei einem Fehler wird \-1 zurückgegeben und \fIerrno\fP gesetzt, um den Fehler anzuzeigen. .SH FEHLER .TP \fBEACCES\fP Für das Verzeichnis, das \fIalterpfad\fP oder \fIneuerpfad\fP enthält, wurden Schreibrechte verweigert oder für eines der Verzeichnisse im Pfad\-Präfix von \fIalterpfad\fP oder \fIneuerpfad\fP wurde nicht gestattet, dort zu suchen oder \fIalterpfad\fP ist ein Verzeichnis und verwehrt die Schreiberlaubnis (benötigt, um den Eintrag \fI..\fP zu aktualisieren). (Siehe auch \fBpath_resolution\fP(7).) .TP \fBEBUSY\fP Das Umbenennen scheitert, weil \fIalterpfad\fP oder \fIneuerpfad\fP ein Verzeichnis ist, das von einem anderen Prozess (vielleicht als aktuelles Arbeitsverzeichnis oder als Wurzelverzeichnis oder weil es zum Lesen geöffnet ist) oder vom System genutzt wird (zum Beispiel als Einhängepunkt) und das System dies als Fehler betrachtet. (Beachten Sie, dass es keine Verpflichtung gibt, in solchen Fällen \fBEBUSY\fP zurückzugeben – es ist nichts falsch daran, die Umbenennung trotzdem durchzuführen – aber es ist erlaubt, \fBEBUSY\fP zurückzugeben, wenn das System solche Situationen nicht anderweitig verarbeiten kann.) .TP \fBEDQUOT\fP Das Plattenkontingent (Quota) des Benutzers an Plattenblöcken auf dem Dateisystem ist erschöpft. .TP \fBEFAULT\fP \fIalterpfad\fP oder \fIneuerpfad\fP zeigt aus dem für Sie zugänglichen Adressraum heraus. .TP \fBEINVAL\fP Der neue Pfadname enthielt ein Pfad\-Präfix des alten, oder allgemeiner, es wurde versucht, ein Verzeichnis als Unterverzeichnis von sich selbst zu erzeugen. .TP \fBEISDIR\fP \fIneuerpfad\fP ist ein existierendes Verzeichnis, aber \fIalterpfad\fP ist kein Verzeichnis. .TP \fBELOOP\fP Bei der Auflösung von \fIalterpfad\fP oder \fIneuerpfad\fP wurden zu viele symbolische Links gefunden. .TP \fBEMLINK\fP \fIalterpfad\fP hat schon die maximale Anzahl Links, oder es war ein Verzeichnis und das Verzeichnis, welches \fIneuerpfad\fP enthält, hat schon die maximale Anzahl Links. .TP \fBENAMETOOLONG\fP \fIalterpfad\fP oder \fIneuerpfad\fP war zu lang. .TP \fBENOENT\fP Der von \fIalterpfad\fP angegebene Link existiert nicht oder eine Verzeichniskomponente von \fIneuerpfad\fP existiert nicht oder \fIalterpfad\fP oder \fIneuerpfad\fP ist eine leere Zeichenkette. .TP \fBENOMEM\fP Es war nicht genügend Kernelspeicher verfügbar. .TP \fBENOSPC\fP Das Gerät, das die die Datei enthält, hat keinen Platz für einen neuen Verzeichniseintrag. .TP \fBENOTDIR\fP Eine als Verzeichnis benutzte Komponente von \fIalterpfad\fP oder \fIneuerpfad\fP ist in der Tat kein Verzeichnis. Oder \fIalterpfad\fP ist ein Verzeichnis und \fIneuerpfad\fP existiert, ist aber kein Verzeichnis. .TP \fBENOTEMPTY\fP oder \fBEEXIST\fP \fIneuerpfad\fP ist ein nicht leeres Verzeichnis, d.h. es enthält außer ».« und »..« weitere Einträge. .TP \fBEPERM\fP oder \fBEACCES\fP Das Verzeichnis, das \fIalterpfad\fP enthält, hat das Sticky\-Bit (\fBS_ISVTX\fP) gesetzt und die effektive Benutzerkennung des Prozesses ist weder die Benutzerkennung der zu löschenden Datei noch die des beinhaltenden Verzeichnisses und der Prozess ist nicht privilegiert (Linux: verfügt nicht über die \fBCAP_FOWNER\fP\-Capability); oder \fIneuerpfad\fP ist eine vorhandene Datei und ihr übergeordnetes Verzeichnis hat das Sticky\-Bit gesetzt und die effektive Benutzerkennung des Prozesses ist weder die Benutzerkennung der zu ersetzenden Datei noch des beherbergenden Verzeichnisses und der Prozess ist nicht privilegiert (Linux: verfügt nicht über die \fBCAP_FOWNER\fP\-Capability) oder das \fIalterpfad\fP beherbergende Dateisystem unterstützt nicht die Umbenennung des angeforderten Typs. .TP \fBEROFS\fP Die Datei befindet sich auf einem nur lesbaren Dateisystem. .TP \fBEXDEV\fP \fIalterpfad\fP und \fIneuerpfad\fP befinden sich nicht auf demselben eingehängten Dateisystem. (Linux erlaubt es Dateisystemen, an mehreren Stellen eingehängt zu sein, aber \fBrename\fP() funktioniert nicht über verschiedene Einhängepunkte hinweg, selbst falls dasselbe Dateisystem an beiden Stellen eingehängt ist.) .PP Die folgenden zusätzlichen Fehler können bei \fBrenameat\fP() und \fBrenameat2\fP() auftreten: .TP \fBEBADF\fP \fIalterpfad\fP (\fIneuerpfad\fP) ist relativ, aber \fIaltVerzdd\fP (\fIneuVerzdd\fP) ist kein zulässiger Dateideskriptor. .TP \fBENOTDIR\fP \fIalterpfad\fP ist relativ und \fIaltVerzdd\fP ist ein Dateideskriptor, der sich auf eine Datei bezieht, die kein Verzeichnis ist; gilt analog für \fIneuerpfad\fP und \fIneuVerzdd\fP. .PP Die folgenden zusätzlichen Fehler können bei \fBrenameat2\fP() auftreten: .TP \fBEEXIST\fP \fISchalter\fP enthält \fBRENAME_NOREPLACE\fP und \fIneuerpfad\fP existiert bereits. .TP \fBEINVAL\fP In \fISchalter\fP wurde ein ungültiger Schalter angegeben. .TP \fBEINVAL\fP Sowohl \fBRENAME_NOREPLACE\fP als auch \fBRENAME_EXCHANGE\fP wurden in \fISchalter\fP angegeben. .TP \fBEINVAL\fP Sowohl \fBRENAME_WHITEOUT\fP als auch \fBRENAME_EXCHANGE\fP wurden in \fISchalter\fP angegeben. .TP \fBEINVAL\fP Das Dateisystem unterstützt einen der Schalter in \fISchalter\fP nicht. .TP \fBENOENT\fP \fISchalter\fP enthält \fBRENAME_EXCHANGE\fP und \fIneuerpfad\fP existiert nicht. .TP \fBEPERM\fP \fBRENAME_WHITEOUT\fP wurde in \fISchalter\fP angegeben, aber der Aufrufende verfügte nicht über die Capability \fBCAP_MKNOD\fP. .SH VERSIONEN \fBrenameat2\fP() wurde zu Linux in Version 3.15 hinzugefügt; Bibliotheksunterstützung wurde zu Glibc 2.28 hinzugefügt. .PP \fBrenameat2\fP() wurde zu Linux in Version 3.15 hinzugefügt; Bibliotheksunterstützung wurde zu Glibc 2.28 hinzugefügt. .SH STANDARDS \fBrename\fP(): 4.3BSD, C99, POSIX.1\-2001, POSIX.1\-2008. .PP \fBrenameat\fP(): POSIX.1\-2008. .PP \fBrenameat2\fP() ist Linux\-spezifisch. .SH ANMERKUNGEN .\" .SS "Anmerkungen zur Glibc" Mit älteren Kerneln, wenn \fBrenameat\fP() nicht verfügbar ist, weicht die Glibc\-Wrapper\-Funktion auf \fBrename\fP() aus. Wenn \fIalterpfad\fP und \fIneuerpfad\fP relative Pfadnamen sind, konstruiert die Glibc Pfadnamen auf Basis der symbolischen Links in \fI/proc/self/fd\fP, die den Argumenten \fIaltVerzdd\fP und \fIneuVerzdd\fP entsprechen. .SH FEHLER Auf NFS\-Dateisystemen kann bei einer fehlgeschlagenen Operation nicht davon ausgegangen werden, dass die Datei nicht umbenannt wurde. Falls der Server die Datei umbenennt und dann abstürzt, gibt der erneut übertragene RPC, der nach dem Wiederanlaufen des Servers verarbeitet wird, einen Fehler zurück. Von der Anwendung wird erwartet, dies zu berücksichtigen. Siehe \fIlink\fP(2) für ein ähnliches Problem. .SH "SIEHE AUCH" \fBmv\fP(1), \fBrename\fP(1), \fBchmod\fP(2), \fBlink\fP(2), \fBsymlink\fP(2), \fBunlink\fP(2), \fBpath_resolution\fP(7), \fBsymlink\fP(7) .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Elmar Jansen , Martin Eberhard Schauer , Helge Kreutzmann und Mario Blättermann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .