Provided by: manpages-de-dev_2.5-1_all 
BEZEICHNUNG
unlink, unlinkat - löscht einen Namen und unter Umständen die Datei, auf die dieser
verweist
ÜBERSICHT
#include <unistd.h>
int unlink(const char *Pfadname);
#include <fcntl.h> /* Definition der AT_*-Konstanten */
#include <unistd.h>
int unlinkat(int dirfd, const char *Pfadname, int Schalter);
Mit Glibc erforderliche Makros (siehe feature_test_macros(7)):
unlinkat():
Seit Glibc 2.10:
_POSIX_C_SOURCE >= 200809L
Vor Glibc 2.10:
_ATFILE_SOURCE
BESCHREIBUNG
unlink() löscht einen Namen aus dem Dateisystem. Falls dieser Name der letzte Link auf
eine Datei war und kein Prozess die Datei geöffnet hält, wird sie gelöscht und der von ihr
belegte Speicherplatz wird für die erneute Verwendung verfügbar gemacht.
Falls dieser Name der letzte Link auf die Datei war, aber diverse Prozesse die Datei noch
geöffnet haben, bleibt die Datei bestehen, bis der letzte auf sie weisende Dateideskriptor
gelöscht wird.
Falls der Name auf einen symbolischen Link verwies, so wird dieser Link entfernt.
Falls der Name auf einen Socket, FIFO oder Gerät verwies, so wird der Name dafür entfernt,
aber Prozesse, die das Objekt geöffnet haben, können es weiterhin benutzen.
unlinkat()
Der Systemaufruf unlinkat() funktioniert genau wie entweder unlink() oder rmdir(2)
(abhängig davon, ob Schalter den Schalter AT_REMOVEDIR enthält), außer den hier
beschriebenen Unterschieden.
Falls der in Pfadname übergebene Pfadname relativ ist wird er relativ zu dem im
Dateideskriptor dirfd referenzierten Verzeichnis interpretiert (statt relativ zum
aktuellen Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei unlink() und rmdir(2)
für einen relativen Pfadnamen der Fall ist).
Falls der in Pfadname übergebene Pfadname relativ ist und dirfd den besonderen Wert
AT_FDCWD enthält wird Pfadname relativ zum aktuellen Arbeitsverzeichnis des aufrufenden
Prozesses interpretiert (wie bei unlink() und rmdir(2)).
Falls der in Pfadname übergebene Pfadname absolut ist, wird dirfd ignoriert.
Schalter ist eine Bitmaske, die entweder als 0 angegeben werden kann, oder mit durch
logisches ODER verknüpften Werten der Schalter, die die Wirkung von unlinkat() steuern.
Gegenwärtig wird nur ein einziger Schalter unterstützt:
AT_REMOVEDIR
Standardmäßig führt unlinkat() das Äquivalent von unlink() auf Pfadname aus. Falls
der Schalter AT_REMOVEDIR angegeben ist, führt es das Äquivalent von rmdir(2) auf
Pfadname aus.
Lesen Sie openat(2) für eine Beschreibung der Notwendigkeit von unlinkat().
RÜCKGABEWERT
Bei Erfolg wird Null zurückgegeben. Bei einem Fehler wird -1 zurückgegeben und errno
entsprechend gesetzt.
FEHLER
EACCES Schreibzugriff auf das Verzeichnis, das Pfadname enthält, ist für die aktuell
effektive UID des Prozesses nicht erlaubt oder eines der Verzeichnisse in Pfadname
gewährt keinen Suchzugriff (siehe auch path_resolution(7)).
EBUSY Für die Datei Pfadname kann der Link nicht gelöst werden, weil er vom System oder
einem anderen Prozess genutzt wird; beispielsweise, wenn er ein Einhängepunkt ist
oder die NFS-Client-Software ihn erstellte, um einen aktiven aber ansonsten
namenlosen Inode zu repräsentieren (»NFS silly renamed«).
EFAULT pathname zeigt aus dem für Sie zugänglichen Adressraum heraus.
EIO Es ist ein E/A-Fehler (engl. I/O) aufgetreten.
EISDIR Pfadname verweist auf ein Verzeichnis. (Dies ist ein nicht-POSIX-Wert, der von
Linux seit 2.1.132 zurückgegeben wird.)
ELOOP Bei der Auflösung von Pfadname wurden zu viele symbolische Verknüpfungen gefunden.
ENAMETOOLONG
pathname war zu lang.
ENOENT Eine Verzeichniskomponente von Pfadname existiert nicht oder ist ein toter
symbolischer Link oder Pfadname ist leer.
ENOMEM Es war nicht genügend Kernelspeicher verfügbar.
ENOTDIR
Eine als Verzeichnis benutzte Komponente von pathname ist kein Verzeichnis.
EPERM Das System verweigert die Aufhebung von Links zu Verzeichnissen oder fordert
Privilegien, die der aufrufende Prozess nicht hat. (Dies ist die von POSIX
vorgeschriebene Fehlerrückgabe. Wie oben erwähnt gibt Linux in diesem Fall EISDIR
zurück.
EPERM (nur Linux)
Das Dateisystem verwehrt das Lösen von Dateilinks.
EPERM oder EACCES
Das Verzeichnis, welches Pfadname enthält, hat das Sticky Bit (S_ISVTX) gesetzt und
die effektive UID des Prozesses ist weder die UID der zu löschenden Datei noch die
UID des Verzeichnisses, das die Datei enthält und der Prozess ist nicht
privilegiert (Linux: ihm fehlt die CAP_FOWNER-Capability).
EPERM Die Datei, deren Link gelöst werden soll, ist unveränderlich oder nur-anhängbar
(siehe ioctl_iflags(2)).
EROFS Pfadname bezieht sich auf eine Datei auf einem schreibgeschützten Dateisystem.
Die gleichen Fehler, die bei unlink() und rmdir(2) auftreten können, können auch für
unlinkat() auftreten. Die folgenden zusätzlichen Fehler können für unlinkat() auftreten:
EBADF dirfd ist kein zulässiger Dateideskriptor.
EINVAL In Schalter wurde ein ungültiger Schalterwert angegeben.
EISDIR Pfadname bezieht sich auf ein Verzeichnis und AT_REMOVEDIR war in Schalter nicht
angegeben.
ENOTDIR
Pfadname ist relativ und dirfd ist ein Dateideskriptor, der sich auf eine Datei
bezieht, die kein Verzeichnis ist.
VERSIONEN
unlinkat() wurde zu Linux in Kernel 2.6.16 hinzugefügt; Bibliotheksunterstützung wurde in
Glibc in Version 2.4 hinzugefügt.
KONFORM ZU
unlink(): SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
unlinkat(): POSIX.1-2008.
ANMERKUNGEN
Anmerkungen zur Glibc
Wenn in älteren Kerneln unlinkat() nicht verfügbar ist, weicht die Glibc-Wrapper-Funktion
auf unlink() oder rmdir(2) aus. Wenn der Pfadname relativ ist, konstruiert die Glibc einen
Pfadnamen, der auf dem symbolischen Link in /proc/self/fd basiert, der dem
newdirfd-Argument entspricht.
FEHLER
Unzulänglichkeiten in dem NFS unterliegenden Protokoll können das unerwartete Verschwinden
von Dateien, welche noch benötigt werden, verursachen.
SIEHE AUCH
rm(1), unlink(1), chmod(2), link(2), mknod(2), open(2), rename(2), rmdir(2), mkfifo(3),
remove(3), 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 Joern Vehoff <joern@vehoff.net>,
Martin Schulze <joey@infodrom.org>, Helge Kreutzmann <debian@helgefjell.de>, Martin
Eberhard Schauer <Martin.E.Schauer@gmx.de>, Mario Blättermann
<mario.blaettermann@gmail.com> und Dr. Tobias Quathamer <toddy@debian.org> 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>.