Rechercher une page de manuel
unlink
Langue: fr
Version: 23 juin 2004 (ubuntu - 16/08/07)
Section: 2 (Appels système)
NOM
unlink - Détruire un nom et éventuellement le fichier associé.SYNOPSIS
#include <unistd.h>int unlink(const char *pathname);
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 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.
VALEUR RENVOYÉE
En cas de réussite, zéro est renvoyé, sinon -1 est renvoyé et errno contient le code d'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. (Voir aussi path_resolution(2).)
- EBUSY (pas sous Linux)
- Le fichier pathname 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.
- EFAULT
- pathname 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
- pathname 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
- Pas assez de mémoire pour le noyau.
- ENOTDIR
- Un élément du chemin d'accès pathname n'est pas 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.
- EROFS
- pathname est placé sur un système de fichiers en lecture seule.
CONFORMITÉ
SVr4, BSD 4.3, POSIX.1-2001.BOGUES
Des problèmes dans le protocole sous-jacent à NFS peuvent causer la disparition inattendue de fichiers encore en utilisation.VOIR AUSSI
rm(1), chmod(2), link(2), mknod(2), open(2), path_resolution(2), rename(2), rmdir(2), unlinkat(2), mkfifo(3), remove(3)TRADUCTION
Cette page de manuel a été traduite et mise à jour par Christophe Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par Alain Portal <aportal AT univ-montp2 DOT fr> jusqu'en 2006.La traduction de cette page de manuel est basée sur les traductions disponibles sur http://manpagesfr.free.fr/, mais est gérée par l'équipe francophone de traduction de Debian au travers de la liste de discussion debian-l10n-french.
Veuillez signaler toute erreur de traduction par un rapport de bogue sur le paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C <section> <page_de_man> ».
-:- SignOff rv_: #linuxfr (Read error: EOF from client)
-:- rv_ [~rv@217.11.166.169] has joined #linuxfr
Contenus ©2006-2008 Benjamin Poulain
Design ©2006-2008 Maxime Vantorre