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

Pages du manuel de Linux 6.8                       2 mai 2024                                        unlinkat(2)