Scroll to navigation

unlink(2) System Calls Manual unlink(2)

NAAM

unlink, unlinkat - verwijder een naam en mogelijk het bestand waarnaar het wijst

BIBLIOTHEEK

Standard C bibliotheek (libc, -lc)

SAMENVATTING

#include <unistd.h>
int unlink(const char *padnaam);
#include <fcntl.h>           /* Definitie van  AT_* constanten */
#include <unistd.h>
int unlinkat(int mapbi, const char *padnaam, int vlaggen);

Feature Test Macro´s eisen in glibc (zie feature_test_macros(7)):

unlinkat():


Vanaf glibc 2.10:
_POSIX_C_SOURCE >= 200809L
Voor glibc 2.10:
_ATFILE_SOURCE

BESCHRIJVING

unlink() verwijderd een naam uit een bestandssysteem. Als die naam de laatste koppeling was van een bestand en geen enkel proces heeft het bestand open, dan wordt het bestand verwijderd en de ruimte die het innam wordt vrijgemaakt om hergebruikt te worden.

Als de naam de laatste koppeling was naar het bestand maar er zijn nog processen die het bestand nog steeds open hebben, dan zal het bestand blijven bestaan totdat de laatste bestandindicator die ernaar verwijst gesloten is.

Als de naam wijst naar een symbolische koppeling dan wordt die koppeling verwijderd.

Als de naam wijst naar een `socket', een fifo of een apparaat dan wordt de naam ervoor verwijderd maar processen die het voorwerp open hebben mogen het blijven gebruiken.

unlinkat()

De unlinkat() systeem aanroep werkt op exact dezelfde manier zoals unlink() of rmdir(2) (afhankelijk van of de flags wel of niet de AT_REMOVEDIR vlag bevat) behalve voor de verschillen zoals hier beschreven.

Als de padnaam gegeven in padnaam is relatief, dan wordt deze geïnterpreteerd relatief aan de map zoals gerefereerd door de bestands beschrijving dirfd (liever dan relatief aan de huidige werkmap van het aanroepende proces, zoals gedaan door unlink() en rmdir(2) voor een relatieve padnaam).

Als de padnaam gegeven in padnaam relatief is en dirfd is de speciale waarde AT_FDCWD, dan zal padnaam geïnterpreteerd worden relatief aan de huidige werk map van het aanroepende proces (zoals unlink() en rmdir(2).

Als de padnaam opgegeven in padnaam absoluut is, dan wordt mapbi genegeerd.

vlaggen is een bit masker dat ofwel gespecificeerd worden als 0, of door de logische OF-bewerking op de waarden van de vlag die de operatie van unlinkat() bepalen. Op dit moment is alleen een zo´n vlag gedefinieerd:

Standaard zal unlinkat() het equivalent van unlink() op padnaam uitvoeren. Indien de AT_REMOVEDIR vlag werd gezet dan werkt het equivalent van rmdir(2) op padnaam.

Zie openat(2) voor een uitleg over het gebruik van unlinkat().

EIND WAARDE

Bij succes wordt nul teruggegeven. Bij falen wordt -1 teruggegeven en wordt errno overeenkomstig gezet.

FOUTEN

Schrijf toegang in de map die padnaam bevat wordt niet toegestaan voor het geldende uid van het proces, of een van de mappen in padnaam liet zoek (voer-uit) toestemming niet toe. (Zie ook path_resolution(7).)
Het bestand padnaam kan niet ontkoppeld worden omdat het in gebruik is door het systeem of door een ander proces; bijvoorbeeld, het is een koppelpunt of NFS client software maakte het aan om een actieve maar anders naamloze inode te vertegenwoordigen ("NFS silly renamed").
padnaam wijst buiten de voor u toegankelijke adresruimte.
Een Invoer/Uitvoer fout trad op.
padnaam wijst naar een map. (Dit is de niet-POSIX waarde teruggegeven sinds Linux 2.1.132.)
Teveel symbolische koppelingen werden tegengekomen bij het vertalen van padnaam.
padnaam was te lang.
Een deel in padnaam bestaat niet of is een loshangende symbolische koppeling, of padnaam is leeg.
Onvoldoende kernelgeheugen voorhanden.
Een onderdeel gebruikt als map in padnaam is in feite geen map.
Het systeem staat ontkoppelen van mappen niet toe, of het ontkoppelen van mappen behoeft privileges die het aanroepende proces niet heeft. (Dit is de voorgeschreven POSIX fout waarde; zoals hierboven beschreven zal Linux in dit geval EISDIR terug geven.)
Het bestandssysteem staat ontkoppeling van bestanden niet toe.
De map waar padnaam in zit heeft het sticky-bit (S_ISVTX) aan staan en het geldende UID van het proces is noch het UID van het bestand dat verwijderd zou worden noch dat van de map waar het in zit en het proces is niet geprivilegieerd (Linux: heeft niet de CAP_FOWNER capaciteit).
Het te ontkoppelen bestand is gemarkeerd als onveranderlijk of alleen-toevoegen. (Zie ioctl_iflags(2).)
padnaam verwijst naar een bestand op een alleen-lezen bestandsysteem.

Dezelfde fouten die optreden in unlink() en rmdir(2) kunnen ook optreden in unlinkat(). De volgende additionele fouten kunnen optreden in unlinkat():

padnaam is relatief en mapbi is noch AT_FDCWD noch een geldige bestandsindicator.
Een ongeldige vlag werd opgegeven in vlaggen.
mapbi wijst naar een map, en AT_REMOVEDIR werd in vlaggen niet opgegeven.
padnaam is relatief en mapbi is een bestandsindicator die naar een bestand wijst die geen map is.

VERSIES

unlinkat() werd toegevoegd in Linux 2.6.16; bibliotheek ondersteuning werd toegevoegd in glibc 2.4.

VOLDOET AAN

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

unlinkat(): POSIX.1-2008.

OPMERKINGEN

Glibc-opmerkingen

Op oudere kernels waar unlinkat() niet beschikbaar is, valt de glibc omwikkel functie terug op het gebruik van unlink of rmdir(2). Wanneer padnaam een relatieve padnaam is, dan construeert glibc een padnaam gebaseerd op de symbolische koppeling in /proc/self/fd overeenkomende met het dirfd argument.

BUGS

Ongelukkigheden in het protocol waar NFS op is gebaseerd kunnen het onverwacht verdwijnen van bestanden veroorzaken die nog steeds gebruikt worden.

ZIE OOK

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)

VERTALING

De Nederlandse vertaling van deze handleiding is geschreven door Jos Boersema <joshb@xs4all.nl>, Mario Blättermann <mario.blaettermann@gmail.com> en Luc Castermans <luc.castermans@gmail.com>

Deze vertaling is vrije documentatie; lees de GNU General Public License Version 3 of later over de Copyright-voorwaarden. Er is geen AANSPRAKELIJKHEID.

Indien U fouten in de vertaling van deze handleiding zou vinden, stuur een e-mail naar debian-l10n-dutch@lists.debian.org.

5 februari 2023 Linux man-pagina's 6.03