Provided by: manpages-fr-dev_4.19.0-7_all bug

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

VERSIONS

       unlinkat() a été ajouté à Linux 2.6.16 ; la prise en  charge  de  la  bibliothèque  a  été
       ajoutée dans la glibc 2.4.

STANDARDS

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

       unlinkat() : POSIX.1-2008.

NOTES

   Notes de la 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⟩.