Provided by: manpages-fr-dev_3.65d1p1-1_all 
NOM
unlink, unlinkat - Détruire un nom et éventuellement le fichier associé
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 (consultez
feature_test_macros(7)) :
unlinkat():
Depuis la glibc 2.10 :
_XOPEN_SOURCE >= 700 || _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 à une 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 qui peut être 0 ou construit par un OU binaire 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
S'il réussit, cet appel système renvoie 0. S'il échoue, il renvoie -1 et remplit errno en
conséquence.
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 pathname 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 par Linux
depuis le 2.1.132).
ELOOP Trop de liens symboliques dans le chemin d'accès pathname.
ENAMETOOLONG
pathname 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 Pas assez de mémoire pour le noyau.
ENOTDIR
Un élément du chemin d'accès pathname n'est pas 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.
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 dirfd n'est pas un descripteur de fichier valable.
EINVAL flags contient un drapeau invalide.
EISDIR pathname est un répertoire et AT_REMOVEDIR n’était pas indiqué dans flags.
ENOTDIR
pathname est relatif, et le descripteur de fichier dirfd est associé à un fichier,
pas à un répertoire.
VERSIONS
unlinkat() a été ajouté au noyau Linux dans sa version 2.6.16 ; la glibc le gère depuis la
version 2.4.
CONFORMITÉ
unlink() : SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
unlinkat() : POSIX.1-2008.
BOGUES
Des problèmes dans le protocole sous-jacent à NFS peuvent provoquer la disparition
inattendue de fichiers encore utilisés.
VOIR AUSSI
rm(1), chmod(2), link(2), mknod(2), open(2), rename(2), rmdir(2), mkfifo(3), remove(3),
path_resolution(7), symlink(7)
COLOPHON
Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies peuvent être trouvées à
l'adresse http://www.kernel.org/doc/man-pages/.
TRADUCTION
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet
perkamon <http://perkamon.alioth.debian.org/>.
Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain Portal
<http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et l'équipe francophone de
traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet
manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la
commande « man -L C <section> <page_de_man> ».