unlink(2)

BEZEICHNUNG
unlink, unlinkat - löscht einen Namen und unter Umständen die Datei, auf die dieser verweist

BIBLIOTHEK
Standard-C-Bibliothek (libc, -lc)

ÜBERSICHT
#include <unistd.h>

int unlink(const char *Pfad);

#include <fcntl.h>           /* Definition der AT_*-Konstanten */
#include <unistd.h>

int unlinkat(int Verzdd, const char *Pfad, int Schalter);

    Mit Glibc erforderliche Feature-Test-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 referenzierte Name ein symbolischer Link ist, wird der 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 Pfad relativ ist, wird er relativ zu dem im Dateideskriptor Verzdd 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 Pfad relativ ist und Verzdd den besonderen Wert AT_FDCWD enthält wird Pfadname relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie bei unlink() und rmdir(2)).

Falls Pfad absolut ist, wird Verzdd 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 Pfad aus. Falls der Schalter AT_REMOVEDIR angegeben ist, führt es das Äquivalent von rmdir(2) auf Pfad 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 gesetzt, um den Fehler anzuzeigen.

FEHLER

EACCES
    Schreibzugriff auf das Verzeichnis, das Pfad enthält, ist für die aktuell effektive UID des Prozesses nicht erlaubt oder eines der Verzeichnisse in Pfad gewährt keinen Suchzugriff (siehe auch path_resolution(7)).

EBUSY
    Für Pfad 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
    Pfad zeigt aus dem für Sie zugänglichen Adressraum heraus.

EIO Es ist ein E/A-Fehler (engl. I/O) aufgetreten.

EISDIR
    Pfad verweist auf ein Verzeichnis. (Dies ist der nicht-POSIX-Wert, der seit Linux 2.1.132 zurückgegeben wird.)

ELOOP
    Bei der Auflösung von Pfad wurden zu viele symbolische Verknüpfungen gefunden.

ENAMETOOLONG
    Pfad war zu lang.

ENOENT
    Eine Verzeichniskomponente von Pfad existiert nicht oder ist ein toter symbolischer Link oder Pfad ist leer.

ENOMEM
    Es war nicht genügend Kernelspeicher verfügbar.

ENOTDIR
    Eine als Verzeichnis benutzte Komponente von Pfad 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 Pfad 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 als unveränderlich oder nur-anhängbar markiert (siehe FS_IOC_SETFLAGS(2const)).

EROFS
    Pfad 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
    Pfad ist relativ, aber Verzdd ist weder AT_FDCWD noch ein gültiger Dateideskriptor.

EINVAL
    In Schalter wurde ein ungültiger Schalterwert angegeben.

EISDIR
    Pfad bezieht sich auf ein Verzeichnis und AT_REMOVEDIR war in Schalter nicht angegeben.

ENOTDIR
    Pfad ist relativ und Verzdd ist ein Dateideskriptor, der sich auf eine Datei bezieht, die kein Verzeichnis ist.

STANDARDS
POSIX.1-2024.

GESCHICHTE

unlink()
    SVr4, 4.3BSD, POSIX.1-2001.

unlinkat()
    POSIX.1-2008. Linux 2.6.16, Glibc 2.4.

  Glibc
Wenn in älteren Kerneln unlinkat() nicht verfügbar ist, weicht die Glibc-Wrapper-Funktion auf unlink() oder rmdir(2) aus. Wenn Pfad relativ ist, konstruiert die Glibc einen Pfadnamen, der auf dem symbolischen Link in /proc/self/fd basiert, der dem Verzdd-Argument entspricht.

FEHLER
Unzulänglichkeiten in dem NFS unterliegenden Protokoll können das unerwartete Verschwinden von Dateien, welche noch verwandt 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)

ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Joern Vehoff <joern@vehoff.net>, Martin Schulze <joey@infodrom.org>, Martin Eberhard Schauer <Martin.E.Schauer@gmx.de>, Helge Kreutzmann <debian@helgefjell.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 (https://www.gnu.org/licenses/gpl-3.0.html) 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 die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.