Provided by: manpages-fr-dev_3.65d1p1-1_all bug

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> ».