Man page - unlink(2)

Packages contains this manual

Available languages:

en fr it pl nl ja ru ro de

Manual

unlinkat

NOM
BIBLIOTHÈQUE
SYNOPSIS
DESCRIPTION
unlinkat()
VALEUR RENVOYÉE
ERREURS
STANDARDS
HISTORIQUE
glibc
BOGUES
VOIR AUSSI
TRADUCTION

NOM

unlink, unlinkat - Détruire un nom et éventuellement le fichier associé

BIBLIOTHÈQUE

BibliothĂšque C standard ( libc , -lc )

SYNOPSIS

#include <unistd.h>

int unlink(const char * pathname );

#include <fcntl.h> /* Définition des constantes AT_* */
#include <unistd.h>

int unlinkat(int dirfd , const char * pathname , int flags );

Exigences de macros de test de fonctionnalités pour la glibc (consulter feature_test_macros (7)) :

unlinkat ():
Depuis la glibc 2.10 :
_POSIX_C_SOURCE >= 200809L
avant la glibc 2.10 :
_ATFILE_SOURCE

DESCRIPTION

unlink () dĂ©truit un nom dans le systĂšme de fichiers. Si ce nom Ă©tait le dernier lien sur un fichier, et si aucun processus n’a ouvert ce fichier, ce dernier est effacĂ©, et l’espace qu’il utilisait est rendu disponible.

Si le nom Ă©tait le dernier lien sur un fichier, mais qu’un processus conserve encore le fichier ouvert, celui-ci continue d’exister jusqu’à ce que le dernier descripteur le rĂ©fĂ©rençant soit fermĂ©.

Si le nom correspond à un lien symbolique, le lien est supprimé.

Si le nom correspond Ă  un socket, une FIFO ou un pĂ©riphĂ©rique, le nom est supprimĂ© mais les processus qui ont ouvert l’objet peuvent continuer Ă  l’utiliser.

unlinkat()

L’appel systĂšme unlinkat () fonctionne exactement comme unlink (2) ou rmdir (2) (en fonction de la prĂ©sence ou non du drapeau AT_REMOVEDIR dans flags ), les seules diffĂ©rences Ă©tant dĂ©crites ici.

Si le chemin donnĂ© dans pathname est relatif, il est interprĂ©tĂ© par rapport au rĂ©pertoire rĂ©fĂ©rencĂ© par le descripteur de fichier dirfd (plutĂŽt que par rapport au rĂ©pertoire de travail, comme c’est le cas pour unlink () et rmdir (2)).

Si le chemin donné dans pathname est relatif et si dirfd a la valeur spéciale AT_FDCWD , alors pathname est interprété par rapport au répertoire de travail du processus appelant (comme pour unlink () et rmdir (2)).

Si le chemin donné dans pathname est absolu, dirfd est ignoré.

flags est un masque de bits qui peut ĂȘtre 0 ou construit par un OU binaire de valeur de drapeaux qui contrĂŽlent le fonctionnement de unlinkat (). Actuellement, un seul drapeau est dĂ©fini :
AT_REMOVEDIR

Par défaut, unlinkat () a un effet équivalent à celui de unlink () sur pathname . Si le drapeau AT_REMOVEDIR est indiqué, unlinkat () fonctionne comme rmdir (2) sur pathname .

Consultez openat (2) pour une explication de la nécessité de unlinkat ().

VALEUR RENVOYÉE

En cas de succĂšs, zĂ©ro est renvoyĂ©. En cas d’erreur, -1 est renvoyĂ© et errno est dĂ©finie pour prĂ©ciser l’erreur.

ERREURS

EACCES

L’accĂšs en Ă©criture au rĂ©pertoire contenant pathname n’est pas autorisĂ© pour l’UID effectif du processus, ou bien l’un des rĂ©pertoires de pathname n’autorise pas le parcours. (Consultez aussi path_resolution (7).)

EBUSY

Le fichier pathname ne peut pas ĂȘtre dĂ©truit avec unlink car il est utilisĂ© par le systĂšme ou par un autre processus ; par exemple, il s’agit d’un point de montage, ou le logiciel client NFS l’a créé pour reprĂ©senter un inƓud actif, mais sinon sans nom (« NFS silly renamed \˜»).

EFAULT

nom_chemin pointe en dehors de l’espace d’adressage accessible.

EIO

Une erreur d’entrĂ©e-sortie s’est produite.

EISDIR

pathname est un rĂ©pertoire. (Il s’agit d’une erreur non-POSIX renvoyĂ©e depuis Linux 2.1.132).

ELOOP

Trop de liens symboliques dans le chemin d’accùs pathname .

ENAMETOOLONG

nom_chemin est trop long.

ENOENT

Un rĂ©pertoire dans le chemin d’accĂšs pathname n’existe pas ou est un lien symbolique pointant nulle part, ou pathname est vide

ENOMEM

La mĂ©moire disponible du noyau n’était pas suffisante.

ENOTDIR

Un Ă©lĂ©ment, utilisĂ© comme rĂ©pertoire, du chemin d’accĂšs nom_chemin n’est pas en fait un rĂ©pertoire.

EPERM

Le systĂšme ne permet pas la destruction des rĂ©pertoires avec unlink, ou cette destruction nĂ©cessite des privilĂšges que le processus appelant n’a pas. (Il s’agit d’une erreur conseillĂ©e par POSIX. Comme prĂ©cisĂ© plus haut, Linux renvoie EISDIR dans ce cas.)

EPERM (spécifique Linux)

Le systĂšme de fichiers ne permet pas la destruction avec unlink.

EPERM ou EACCES

Le rĂ©pertoire contenant pathname a son sticky bit ( S_ISVTX ) Ă  1, et l’UID effectif du processus n’est ni celui du fichier ni celui du rĂ©pertoire et le processus n’est pas privilĂ©giĂ© (sous Linux : n’a pas la capacitĂ© CAP_FOWNER .

EPERM

Le fichier Ă  dĂ©truire avec unlink est marquĂ© immuable ou comme n’acceptant que des ajouts. (Voir FS_IOC_SETFLAGS (2const).)

EROFS

pathname est placé sur un systÚme de fichiers en lecture seule.

Les erreurs supplémentaires suivantes peuvent également se produire pour unlinkat () :

EBADF

pathname est relatif mais dirfd n’est ni AT_FDWCD ni un descripteur de fichier valable.

EINVAL

flags contient un drapeau non valable.

EISDIR

pathname est un rĂ©pertoire et AT_REMOVEDIR n’était pas indiquĂ© dans flags .

ENOTDIR

pathname est relatif et dirfd est un descripteur de fichier faisant rĂ©fĂ©rence Ă  un fichier qui n’est pas un dossier.

STANDARDS

POSIX.1-2008.

HISTORIQUE

unlink ()

SVr4, 4.3BSD, POSIX.1-2001.

unlinkat ()

POSIX.1-2008. Linux 2.6.16, glibc 2.4.

glibc

Avec les anciens noyaux oĂč unlinkat () n’est pas disponible, la fonction d’enveloppe de la glibc se replie sur l’utilisation de unlink () ou rmdir (2). Qaund pathname est un nom de chemin relatif, glibc construit un nom de chemin basĂ© sur le lien symbolique dans /proc/self/fd qui correspond Ă  l’argument dirfd .

BOGUES

Des problÚmes dans le protocole sous-jacent à NFS peuvent provoquer la disparition inattendue de fichiers encore utilisés.

VOIR AUSSI

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)

TRADUCTION

La traduction française de cette page de manuel a été créée par Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot <david@tilapin.org>, Frédéric Hantrais <fhantrais@gmail.com> et Jean-Pierre Giraud <jean-pierregiraud@neuf.fr>

Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n’y a aucune RESPONSABILITÉ LÉGALE.

Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org .