Ubuntu Manpage: unlink, unlinkat - Détruire un nom et éventuellement le fichier associé

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 (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  is a bit mask that can either be specified as 0, or by ORing together flag values that control the
       operation of unlinkat(). Currently, only one such flag is defined:

       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 reçoit une valeur adéquate.

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 par Linux depuis le
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 The file to be unlinked is marked immutable or append-only. (See 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 dirfd n'est pas 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é 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.

NOTES

   Notes de la glibc
       On older kernels where unlinkat()  is unavailable, the glibc wrapper function falls back to  the  use  of
       unlink()   or  rmdir(2).  When  pathname is a relative pathname, glibc constructs a pathname based on the
       symbolic link in /proc/self/fd that corresponds to the dirfd argument.

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)

COLOPHON

       Cette page fait partie de la publication 5.10 du projet man-pages Linux. Une description du projet et des
       instructions  pour  signaler  des  anomalies et la dernière version de cette page peuvent être trouvées à
       l'adresse https://www.kernel.org/doc/man-pages/.

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> et Frédéric Hantrais <fhantrais@gmail.com>

       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.

Linux                                           15 septembre 2017                                      UNLINK(2)