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\[u00A0]»).

       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 ioctl_iflags(2).)

       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  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩   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⟩.