unlink

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);

unlinkat():

    Depuis la version 2.10 de la glibc :
        _POSIX_C_SOURCE >= 200809L
    Avant la version 2.10 de la glibc :
        _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 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 <[email protected]>, Thierry Vignaud <[email protected]>, François Micaux, Alain Portal <[email protected]>, Jean-Philippe Guérard <[email protected]>, Jean-Luc Coulon (f5ibh) <[email protected]>, Julien Cristau <[email protected]>, Thomas Huriaux <[email protected]>, Nicolas François <[email protected]>, Florentin Duneau <[email protected]>, Simon Paillard <[email protected]>, Denis Barbier <[email protected]>, David Prévot <[email protected]>, Frédéric Hantrais <[email protected]> et Jean-Pierre Giraud <[email protected]> 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 à [email protected]