Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] unlink - Détruire un nom et éventuellement le fichier associé. [size=18] [b]Résumé[/b] [/size] [b]#include <unistd.h>[/b] [b][i]int unlink(const char * pathname );[/i][/b] [size=18] [b]Description[/b] [/size] [b]unlink[/b] 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 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 effacé. Si le nom correspond à une socket, une Fifo, ou un périphérique, le nom est effacé mais les processus qui ont ouvert l'objet peuvent continuer à l'utiliser. [size=18] [b]Valeur renvoyée[/b] [/size] [b]unlink[/b] renvoie 0 s'il réussit ou -1 s'il échoue, auquel cas [i]errno[/i] contient le code d'erreur. [size=18] [b]Erreurs[/b] [/size] [b]EACCES[/b] [table][row][col]    [/col][col]L'accès en écriture au répertoire contenant [i]pathname[/i] n'est pas autorisé pour l'UID effectif du processus, ou bien l'un des répertoires de [b]pathname[/b] n'autorise pas le parcours.[/col][/row][/table] [b]EPERM ou EACCESS[/b] [table][row][col]    [/col][col]Le répertoire contenant [i]pathname[/i] a son Sticky-Bit à 1, et l'UID effectif du processus n'est ni celui du fichier ni celui du répertoire.[/col][/row][/table] [b]EPERM (spécifique Linux)[/b] [table][row][col]    [/col][col]Le système de fichiers ne permet pas la destruction avec unlink.[/col][/row][/table] [b]EPERM[/b] [table][row][col]    [/col][col]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).[/col][/row][/table] [b]EISDIR[/b] [b]pathname est un répertoire.[/b] [table][row][col]    [/col][col](Il s'agit d'une erreur non-POSIX renvoyée par Linux depuis le 2.1.132).[/col][/row][/table] [b]EBUSY (spécifique Linux)[/b] [table][row][col]    [/col][col]Le fichier [i]pathname[/i] ne peut pas être détruit avec unlink car il est utilisé par le système ou par un autre processus, et l'implémentation considère que c'est une erreur.[/col][/row][/table] [b]EFAULT[/b] [b]pathname pointe en dehors de l'espace d'adressage accessible[/b][/col][/row][/table] [b]ENAMETOOLONG[/b] [b]pathname est trop long.[/b][/col][/row][/table] [b]ENOENT[/b] [table][row][col]    [/col][col]Un répertoire dans le chemin d'accès [i]pathname[/i] n'existe pas ou est un lien symbolique pointant nulle part.[/col][/row][/table] [b]ENOTDIR[/b] [table][row][col]    [/col][col]Un élément du chemin d'accès [i]pathname[/i] n'est pas un répertoire. [b]ENOMEM[/b] pas assez de mémoire pour le noyau[/col][/row][/table] [b]EROFS[/b] [i]pathname[/i] [table][row][col]    [/col][col]est placé sur un système de fichiers en lecture seule.[/col][/row][/table] [b]ELOOP[/b] [table][row][col]    [/col][col]Trop de liens symboliques dans le chemin d'accès [b]pathname .[/b][/col][/row][/table] [b]EIO[/b] [table][row][col]    [/col][col]une erreur d'entrée/sortie bas-niveau s'est produite.[/col][/row][/table] [size=18] [b]Conformité[/b] [/size] SVr4, SVID, POSIX, X/OPEN, BSD 4.3. SVr4 mentionne les conditions d'erreur supplémentaires EINTR, EMULTIHOP, ETXTBSY, ENOLINK. [size=18] [b]Bugs[/b] [/size] Des problèmes dans le protocole sous-jacent à NFS peuvent causer la disparition inattendue de fichiers encore en utilisation. [size=18] [b]Voir aussi[/b] [/size] [b]link (2),[/b] [b]rename (2),[/b] [b]open (2),[/b] [b]rmdir (2),[/b] [b]mknod (2),[/b] [b]mkfifo (3),[/b] [b]remove (3),[/b] [b]rm (1).[/b] [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 1996-2003.
Fichier