Provided by: manpages-de-dev_2.5-1_all 
BEZEICHNUNG
rename, renameat, renameat2 - den Namen oder die Lage einer Datei ändern
ÜBERSICHT
#include <stdio.h>
int rename(const char *oldpath, const char *newpath);
#include <fcntl.h> /* Definition der AT_*-Konstanten */
#include <stdio.h>
int renameat(int olddirfd, const char *oldpath,
int newdirfd, const char *newpath);
int renameat2(int olddirfd, const char *oldpath,
int newdirfd, const char *newpath, unsigned int flags);
Hinweis: Es gibt keinen Glibc-Wrapper für renameat2(); siehe ANMERKUNGEN.
Mit Glibc erforderliche Makros (siehe feature_test_macros(7)):
renameat():
Seit Glibc 2.10:
_POSIX_C_SOURCE >= 200809L
Vor Glibc 2.10:
_ATFILE_SOURCE
BESCHREIBUNG
rename() benennt eine Datei um und verschiebt sie in ein anderes Verzeichnis, wenn nötig. Alle anderen
Hard Links (erstellt mittels link(2)) sind nicht betroffen, ebenso offene Dateideskriptoren für oldpath.
Verschiedene Einschränkungen bestimmen, ob die Umbenennungsaktion erfolgreich ist oder nicht; siehe
FEHLER unten.
Falls newpath schon existiert, wird er in einem atomaren Schritt überschrieben, so dass ein anderer
Prozess jederzeit auf newpath zugreifen kann. Allerdings wird es wahrscheinlich ein Fenster geben, in dem
sowohl oldpath als auch newpath sich auf die umzubenennende Datei beziehen.
Falls oldpath und newpath bestehende Hard Links zu derselben Datei sind, tut rename() nichts und meldet
eine erfolgreiche Ausführung.
Wenn newpath schon existiert, aber das Umbenennen aus irgendeinem Grund fehlschlägt, garantiert rename(),
dass newpath an Ort und Stelle erhalten bleibt.
oldpath kann ein Verzeichnis angeben. In diesem Fall darf newpath nicht existieren oder muss ein leeres
Verzeichnis angeben.
Falls oldpath auf einen symbolischen Link zeigt, wird der Link umbenannt; falls newpath auf einen
symbolischen Link zeigt, wird der Link überschrieben.
renameat()
Der Systemaufruf renameat() funktioniert genauso wie rename(), außer den hier beschriebenen
Unterschieden.
Falls der in oldpath übergebene Pfadname relativ ist wird er als relativ zu dem im Dateideskriptor
olddirfd referenzierten Verzeichnis interpretiert (statt relativ zum aktuellen Arbeitsverzeichnis des
aufrufenden Prozesses, wie es bei rename() für einen relativen Pfadnamen erfolgt).
Falls oldpath relativ ist und olddirfd den besonderen Wert AT_FDCWD annimmt wird oldpath als relativ zum
aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie rename()).
Falls oldpath absolut ist wird olddirfd ignoriert.
Die Interpretation von newpath ist wie bei oldpath, außer dass ein relativer Pfadname als relativ zu dem
Verzeichnis interpretiert wird, auf das der Dateideskriptor newdirfd verweist.
Lesen Sie openat(2) für eine Beschreibung der Notwendigkeit von renameat().
renameat2()
renameat2() hat ein zusätzliches Argument flags. Ein Aufruf von renameat2() mit einem leeren Argument
flags ist äquivalent zu renameat().
Das Argument flags ist eine Bitmaske, die aus null oder mehr der folgenden Schalter besteht:
RENAME_EXCHANGE
tauscht oldpath und newpath 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.
RENAME_NOREPLACE
überschreibt newpath beim Umbenennen nicht. Ein Fehler wird zurückgegeben, wenn newpath bereits
existiert.
RENAME_NOREPLACE kann nicht zusammen mit RENAME_EXCHANGE eingesetzt werden.
RENAME_WHITEOUT (seit Linux 3.18)
This operation makes sense only for overlay/union filesystem implementations.
Durch Angabe von RENAME_WHITEOUT 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.
A "whiteout" is an object that has special meaning in union/overlay filesystem constructs. In
these constructs, multiple layers exist and only the top one is ever modified. A whiteout on an
upper layer will effectively hide a matching file in the lower layer, making it appear as if the
file didn't exist.
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.
When not part of a union/overlay, the whiteout appears as a character device with a {0,0} device
number.
RENAME_WHITEOUT benötigt die gleichen Privilegien wie zum Erstellen eines Geräteknotens (d.h. die
Capability CAP_MKNOD).
RENAME_WHITEOUT kann nicht zusammen mit RENAME_EXCHANGE eingesetzt werden.
RENAME_WHITEOUT benötigt die Unterstützung vom darunterliegenden Dateisystem. Unter den
Dateisystemen, die die Unterstützung anbieten, sind Shmem (seit Linux 3.18), Ext4 (seit Linux
3.18) und XFS (seit Linux 4.1).
RÜCKGABEWERT
Bei Erfolg wird Null zurückgegeben. Bei einem Fehler wird -1 zurückgegeben und errno entsprechend
gesetzt.
FEHLER
EACCES Für das Verzeichnis, das oldpath oder newpath enthält, wurden Schreibrechte verweigert oder für
eines der Verzeichnisse im Pfad-Präfix von oldpath oder newpath wurde nicht gestattet, dort zu
suchen oder oldpath ist ein Verzeichnis und verwehrt die Schreiberlaubnis (benötigt, um den
Eintrag .. zu aktualisieren). (Siehe auch path_resolution(7).)
EBUSY Das Umbenennen scheitert, weil oldpath oder newpath ein Verzeichnis ist, das von einem anderen
Prozess (vielleicht als aktuelles Arbeitsverzeichnis oder als Root-Verzeichnis 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
EBUSY zurückzugeben – es ist nichts falsch daran, die Umbenennung trotzdem durchzuführen – aber es
ist erlaubt, EBUSY zurückzugeben, wenn das System solche Situationen nicht anderweitig verarbeiten
kann.)
EDQUOT Das Quota (Plattenkontingent) des Benutzers an Plattenblöcken auf dem Dateisystem ist erschöpft.
EFAULT alterpfad oder neuerpfad zeigt aus dem für Sie zugänglichen Adressraum heraus.
EINVAL Der neue Pfadname enthielt ein Pfad-Präfix des alten, oder allgemeiner, es wurde versucht, ein
Verzeichnis als Unterverzeichnis von sich selbst zu erzeugen.
EISDIR newpath ist ein existierendes Verzeichnis, aber oldpath ist kein Verzeichnis.
ELOOP Bei der Auflösung von oldpath oder newpath wurden zu viele symbolische Links gefunden.
EMLINK oldpath hat schon die maximale Anzahl Links, oder es war ein Verzeichnis und das Verzeichnis,
welches newpath enthält, hat schon die maximale Anzahl Links.
ENAMETOOLONG
oldpath oder newpath war zu lang.
ENOENT Der von oldpath angegebene Link existiert nicht oder eine Verzeichniskomponente von newpath
existiert nicht oder oldpath oder newpath ist eine leere Zeichenkette.
ENOMEM Es war nicht genügend Kernelspeicher verfügbar.
ENOSPC Das Gerät, das die die Datei enthält, hat keinen Platz für einen neuen Verzeichniseintrag.
ENOTDIR
Eine als Verzeichnis benutzte Komponente von oldpath oder newpath ist in der Tat kein Verzeichnis.
Oder oldpath ist ein Verzeichnis und newpath existiert, ist aber kein Verzeichnis.
ENOTEMPTY oder EEXIST
newpath ist ein nicht leeres Verzeichnis, d.h. es enthält außer ».« und »..« weitere Einträge.
EPERM oder EACCES
Das Verzeichnis, das oldpath enthält, hat das Sticky-Bit (S_ISVTX) gesetzt und die effektive
Benutzer-ID des Prozesses ist weder die Benutzer-ID der zu löschenden Datei noch die des
beinhaltenden Verzeichnisses und der Prozess ist nicht privilegiert (Linux: verfügt nicht über die
CAP_FOWNER-Capability); oder newpath ist eine vorhandene Datei und ihr übergeordnetes Verzeichnis
hat das Sticky-Bit gesetzt und die effektive Benutzer-ID des Prozesses ist weder die Benutzer-ID
der zu ersetzenden Datei noch des beherbergenden Verzeichnisses und der Prozess ist nicht
privilegiert (Linux: verfügt nicht über die CAP_FOWNER-Capability) oder das pathname beherbergende
Dateisystem unterstützt nicht die Umbenennung des angeforderten Typs.
EROFS Die Datei befindet sich auf einem nur lesbaren Dateisystem.
EXDEV oldpath und newpath befinden sich nicht auf demselben eingehängten Dateisystem. (Linux erlaubt es
Dateisystemen, an mehreren Stellen eingehängt zu sein, aber rename() funktioniert nicht über
verschiedene Einhängepunkte hinweg, selbst falls dasselbe Dateisystem an beiden Stellen eingehängt
ist.)
Die folgenden zusätzlichen Fehler können bei renameat() und renameat2() auftreten:
EBADF olddirfd oder newdirfd ist kein zulässiger Dateideskriptor.
ENOTDIR
oldpath ist relativ und olddirfd ist ein Dateideskriptor, der sich auf eine Datei bezieht, die
kein Verzeichnis ist; gilt analog für newpath and newdirfd.
Die folgenden zusätzlichen Fehler können bei renameat2() auftreten:
EEXIST flags enthält RENAME_NOREPLACE und newpath existiert bereits.
EINVAL In flags wurde ein ungültiger Schalter angegeben.
EINVAL Sowohl RENAME_NOREPLACE als auch RENAME_EXCHANGE wurden in flags angegeben.
EINVAL Sowohl RENAME_WHITEOUT als auch RENAME_EXCHANGE wurden in flags angegeben.
EINVAL Das Dateisystem unterstützt einen der Schalter in flags nicht.
ENOENT flags enthält RENAME_EXCHANGE und newpath existiert nicht.
EPERM RENAME_WHITEOUT wurde in flags festgelegt, aber der Aufrufende verfügte nicht über die Capability
CAP_MKNOD.
VERSIONEN
renameat() wurde zu Linux in Kernel 2.6.16 hinzugefügt; Bibliotheksunterstützung wurde zu Glibc in
Version 2.4 hinzugefügt.
renameat2() wurde zu Linux in Kernel 3.15 hinzugefügt.
KONFORM ZU
rename(): 4.3BSD, C89, C99, POSIX.1-2001, POSIX.1-2008.
renameat(): POSIX.1-2008.
renameat2() ist Linux-spezifisch.
ANMERKUNGEN
Glibc stellt keinen Wrapper für den Systemaufruf renameat2() bereit; rufen Sie ihn mittels syscall(2)
auf.
Anmerkungen zur Glibc
Mit älteren Kerneln, wenn renameat() nicht verfügbar ist, weicht die Glibc-Wrapper-Funktion auf rename()
aus. Wenn oldpath und newpath relative Pfadnamen sind, konstruiert die Glibc Pfadnamen auf Basis der
symbolischen Links in /proc/self/fd, die den Argumenten olddirfd und newdirfd entsprechen.
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 link(2) für ein ähnliches Problem.
SIEHE AUCH
mv(1), chmod(2), link(2), symlink(2), unlink(2), path_resolution(7), symlink(7)
KOLOPHON
Diese Seite ist Teil der Veröffentlichung 4.15 des Projekts Linux-man-pages. Eine Beschreibung des
Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden
sich unter https://www.kernel.org/doc/man-pages/.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Elmar Jansen <ej@pumuckel.gun.de>, Helge
Kreutzmann <debian@helgefjell.de>, Martin Eberhard Schauer <Martin.E.Schauer@gmx.de> und Mario
Blättermann <mario.blaettermann@gmail.com> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer
bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an
<debian-l10n-german@lists.debian.org>.