.\" -*- coding: UTF-8 -*- .\" This manpage is Copyright (C) 1992 Drew Eckhardt; .\" and Copyright (C) 1993 Michael Haardt; .\" and Copyright (C) 1993,1995 Ian Jackson .\" and Copyright (C) 2006, 2014 Michael Kerrisk .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" Modified Sat Jul 24 00:35:52 1993 by Rik Faith .\" Modified Thu Jun 4 12:21:13 1998 by Andries Brouwer .\" Modified Thu Mar 3 09:49:35 2005 by Michael Haardt .\" 2007-03-25, mtk, added various text to DESCRIPTION. .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH RENAME 2 "6 mars 2019" Linux "Manuel du programmeur Linux" .SH NOM rename, renameat, renameat2 \- Changer le nom ou l'emplacement d'un fichier .SH SYNOPSIS .nf \fB#include \fP .PP \fBint rename(const char *\fP\fIoldpath\fP\fB, const char *\fP\fInewpath\fP\fB);\fP \fB#include \fP /* Définition des constantes AT_* */ \fB#include \fP .PP \fBint renameat(int \fP\fIolddirfd\fP\fB, const char *\fP\fIoldpath\fP\fB,\fP \fB int \fP\fInewdirfd\fP\fB, const char *\fP\fInewpath\fP\fB);\fP .PP \fBint renameat2(int \fP\fIolddirfd\fP\fB, const char *\fP\fIoldpath\fP\fB,\fP \fB int \fP\fInewdirfd\fP\fB, const char *\fP\fInewpath\fP\fB, unsigned int \fP\fIflags\fP\fB);\fP .fi .PP .in -4n Exigences de macros de test de fonctionnalités pour la glibc (consulter \fBfeature_test_macros\fP(7))\ : .in .PP \fBrenameat\fP()\ : .PD 0 .ad l .RS 4 .TP 4 Depuis la glibc 2.10\ : _POSIX_C_SOURCE\ >=\ 200809L .TP Avant la glibc 2.10\ : _ATFILE_SOURCE .RE .PP \fBrenameat2\fP()\ : .RS 4 .TP _GNU_SOURCE .RE .ad .PD .SH DESCRIPTION \fBrename\fP() renomme un fichier, en le déplaçant dans un autre répertoire si nécessaire. Tous les autres liens physiques vers le fichier (comme créés avec \fBlink\fP(2)) sont inchangés. Les descripteurs de fichier ouverts sur \fIoldpath\fP ne sont pas non plus affectés. .PP Diverses restrictions déterminent si l’opération de renommage a réussie. Consulter le paragraphe ERREURS ci\-après. .PP Si \fInewpath\fP existe déjà, il sera remplacé de manière atomique, de manière à ce qu'à aucun moment, un autre processus tentant d'accéder à \fInewpath\fP ne le voie absent. Cependant, il existera probablement un créneau pendant lequel \fIoldpath\fP et \fInewpath\fP se référeront au fichier en cours de renommage. .PP Si \fIoldpath\fP et \fInewpath\fP sont des liens physiques existants correspondant au même fichier, \fBrename\fP() ne fait rien et renvoie un code de succès. .PP Si \fInewpath\fP existe mais que l'opération échoue pour une raison quelconque, \fBrename\fP() garantit la présence d'une instance de \fInewpath\fP en place. .PP \fIoldpath\fP peut être un répertoire. Dans ce cas, \fInewpath\fP doit être soit absent, soit un répertoire vide. .PP Si \fIoldpath\fP correspond à un lien symbolique, le lien est renommé\ ; si \fInewpath\fP correspond à un lien symbolique, le lien est écrasé. .SS renameat() L'appel système \fBrenameat\fP() fonctionne exactement comme \fBrename\fP(), les seules différences étant décrites ici. .PP Si le chemin donné dans \fIoldpath\fP est relatif, il est interprété par rapport au répertoire référencé par le descripteur de fichier \fIolddirfd\fP (plutôt que par rapport au répertoire de travail du processus, comme c'est le cas pour \fBrename\fP()). .PP Si \fIoldpath\fP est un chemin relatif, et si \fIolddirfd\fP a la valeur spéciale \fBAT_FDCWD\fP, alors \fIoldpath\fP est interprété par rapport au répertoire de travail du processus (comme pour \fBrename\fP()). .PP Si \fIoldpath\fP est un chemin absolu, \fIolddirfd\fP est ignoré. .PP L'interprétation de \fInewpath\fP est identique à celle de \fIoldpath\fP, excepté qu'un chemin relatif est interprété par rapport au répertoire correspondant à \fInewdirfd\fP. .PP Consultez \fBopenat\fP(2) pour une explication de la nécessité de \fBrenameat\fP(). .SS renameat2() \fBrenameat2\fP() possède un argument additionnel, \fIflags\fP. Un appel à \fBrenameat2\fP() sans passer de valeur à l'argument \fIflags\fP équivaut à un appel à \fBrenameat\fP(). .PP L'argument \fIflags\fP est un masque de bits éventuellement vide ou contenant un ou plusieurs des attributs suivants\ : .TP \fBRENAME_EXCHANGE\fP Échange \fIoldpath\fP et \fInewpath\fP par une opération atomique. Les deux chemins doivent exister mais peuvent être de différentes natures (par exemple, l'un peut être un répertoire non vide et l'autre un lien symbolique). .TP \fBRENAME_NOREPLACE\fP Ne pas écraser \fInewpath\fP lors du renommage. Renvoi d’une erreur si \fInewpath\fP existe déjà. .IP \fBRENAME_NOREPLACE\fP ne peut être employer en même temps que \fBRENAME_EXCHANGE\fP. .IP \fBRENAME_NOREPLACE\fP nécessite une prise en charge par le système de fichiers sous\-jacent. Cette prise en charge pour divers systèmes de fichiers a été ajoutée comme suit\ : .RS .IP * 3 .\" ext4: commit 0a7c3937a1f23f8cb5fc77ae01661e9968a51d0c ext4 (Linux\ 3.15)\ ; .IP * btrfs, shmem et cifs (Linux\ 3.17)\ ; .IP * .\" btrfs: commit 80ace85c915d0f41016f82917218997b72431258 .\" shmem: commit 3b69ff51d087d265aa4af3a532fc4f20bf33e718 .\" cifs: commit 7c33d5972ce382bcc506d16235f1e9b7d22cbef8 .\" .\" gfs2 in 4.2? xfs (Linux\ 4.0)\ ; .IP * .\" Also affs, bfs, exofs, hfs, hfsplus, jffs2, logfs, msdos, .\" nilfs2, omfs, sysvfs, ubifs, udf, ufs .\" hugetlbfs, ramfs .\" local filesystems: commit f03b8ad8d38634d13e802165cc15917481b47835 .\" libfs: commit e0e0be8a835520e2f7c89f214dfda570922a1b90 La prise en charge pour plusieurs autres systèmes de fichiers a été ajoutée dans Linux\ 4.9, dont ext2, minix, reiserfs, jfs, vfat et bpf. .RE .TP \fBRENAME_WHITEOUT\fP (depuis Linux 3.18) .\" commit 0d7a855526dd672e114aff2ac22b60fc6f155b08 .\" commit 787fb6bc9682ec7c05fb5d9561b57100fbc1cc41 Cette opération n’a de sens que pour les implémentations de système de fichiers overlay/union. .IP L’indication de \fBRENAME_WHITEOUT\fP crée un objet de «\ whiteout\ » (simulation d’effacement) à la source du renommage en même temps que la réalisation de ce renommage. Toute l’opération est atomique, de telle façon que si le renommage réussit, alors le whiteout est aussi créé. .IP Un «\ whiteout\ » est un objet de signification spéciale dans les constructions de système de fichiers union/overlay. Dans ces constructions, plusieurs couches existent et seule la plus haute est toujours modifiée. Un whiteout sur la couche supérieure cachera de fait un fichier apparié dans la couche inférieure, donnant l’impression que le fichier n’existe pas. .IP Lorsqu’un fichier existant dans la couche inférieure est renommé, le fichier est d’abord copié au niveau supérieur (s’il n’existe pas déjà sur ce niveau) puis est renommé sur la couche en lecture\-écriture supérieure. Au même moment, le fichier source doit être mis «\ whiteout\ » (de façon que la version dans la couche inférieure soit rendue invisible). Toute l’opération doit être réalisée de manière atomique. .IP .\" https://www.freebsd.org/cgi/man.cgi?query=mount_unionfs&manpath=FreeBSD+11.0-RELEASE Lorsqu’il ne fait pas partie d’une union/overlay, le whiteout apparaît comme un périphérique caractère avec un numéro de périphérique. (Il est à remarquer que les implémentations union/overlay peuvent employer des méthodes différentes pour stocker les entrées whiteout. Précisément, les unions de montage BSD utilisent un type d’inode distinct, \fBDT_WHT\fP, lesquels, tout en étant gérés par certains systèmes de fichiers disponibles dans Linux, tels que CODA et XFS, sont ignorés par le code de prise en charge du noyau pour whiteout, comme pour au moins, Linux\ 4.19.) .IP \fBRENAME_WHITEOUT\fP nécessite les mêmes droits que pour la création d’un nœud de périphérique (c'est\-à\-dire, la capacité \fBCAP_MKNOD\fP). .IP \fBRENAME_WHITEOUT\fP ne peut être employé en même temps que \fBRENAME_EXCHANGE\fP. .IP .\" tmpfs: commit 46fdb794e3f52ef18b859ebc92f0a9d7db21c5df .\" ext4: commit cd808deced431b66b5fa4e5c193cb7ec0059eaff .\" XFS: commit 7dcf5c3e4527cfa2807567b00387cf2ed5e07f00 .\" f2fs: commit 7e01e7ad746bc8198a8b46163ddc73a1c7d22339 .\" btrfs: commit cdd1fedf8261cd7a73c0596298902ff4f0f04492 .\" ubifs: commit 9e0a1fff8db56eaaebb74b4a3ef65f86811c4798 \fBRENAME_WHITEOUT\fP nécessite une prise en charge par le système de fichiers sous\-jacent. Entre autres les systèmes de fichiers tmpfs (depuis Linux\ 3.18), ext4 (depuis Linux\ 3.18), XFS (depuis Linux\ 4.1), f2fs (depuis Linux\ 4.2), btrfs (depuis Linux\ 4.7) et ubifs (depuis Linux\ 4.9) fournissent cette prise en charge. .SH "VALEUR RENVOYÉE" En cas de succès, zéro est renvoyé. En cas d'erreur, \fB\-1\fP est renvoyé et \fIerrno\fP reçoit une valeur adéquate. .SH ERREURS .TP \fBEACCES\fP La permission d'écrire est refusée dans le répertoire contenant \fIoldpath\fP ou \fInewpath\fP, ou la permission de parcours est refusée pour l'un des répertoires dans le chemin d’accès à \fIoldpath\fP ou \fInewpath\fP, ou encore \fIoldpath\fP est un répertoire et ne permet pas l'écriture (nécessaire pour mettre à jour l'entrée \fI..\fP). (Consultez aussi \fBpath_resolution\fP(7).) .TP \fBEBUSY\fP Le renommage a échoué car \fIoldpath\fP ou \fInewpath\fP est un répertoire utilisé par un processus (peut\-être comme répertoire de travail, ou comme répertoire racine, ou ouvert en lecture), ou il est utilisé par le système (comme point de montage par exemple). Le système a donc considéré qu'il y avait une erreur. (Notez qu'il n'est pas indispensable de renvoyer \fBEBUSY\fP dans un tel cas \(em\ rien n'empêche d'effectuer le renommage malgré tout\ \(em mais il est permis de retourner \fBEBUSY\fP si le système n'arrive pas à gérer une telle situation). .TP \fBEDQUOT\fP Le quota de blocs de disque de l'utilisateur sur le système de fichiers a été atteint. .TP \fBEFAULT\fP \fIoldpath\fP ou \fInewpath\fP pointent en dehors de l'espace d'adressage accessible. .TP \fBEINVAL\fP Le nouveau chemin contient un préfixe de chemin de l’ancien, ou plus généralement, un répertoire ne peut pas être déplacé dans ses propres sous\-répertoires. .TP \fBEISDIR\fP \fInewpath\fP est un répertoire existant mais \fIoldpath\fP n'est pas un répertoire .TP \fBELOOP\fP Trop de liens symboliques ont été rencontrés en parcourant \fIoldpath\fP ou \fInewpath\fP. .TP \fBEMLINK\fP \fIoldpath\fP a déjà un nombre maximal de liens, ou bien c'est un répertoire, et le répertoire contenant \fInewpath\fP a le nombre maximal de liens. .TP \fBENAMETOOLONG\fP \fIoldpath\fP ou \fInewpath\fP est trop long. .TP \fBENOENT\fP Le lien indiqué par \fIoldpath\fP n'existe pas, ou bien un répertoire du chemin \fInewpath\fP n'existe pas, ou bien \fIoldpath\fP ou \fInewpath\fP est une chaîne vide. .TP \fBENOMEM\fP La mémoire disponible du noyau n'était pas suffisante. .TP \fBENOSPC\fP Le périphérique contenant le fichier n'a pas de place pour une nouvelle entrée de répertoire. .TP \fBENOTDIR\fP Un élément utilisé comme répertoire dans \fIoldpath\fP ou \fInewpath\fP n'est pas un répertoire, ou bien \fIoldpath\fP est un répertoire et \fInewpath\fP existe mais n'est pas un répertoire. .TP \fBENOTEMPTY\fP ou \fBEEXIST\fP \fInewpath\fP est un répertoire non vide (contient autre chose que «\ .\ » et «\ ..\ »). .TP \fBEPERM\fP ou \fBEACCES\fP Le répertoire contenant \fIoldpath\fP a le sticky bit (\fBS_ISVTX\fP) positionné, et l'UID effectif du processus n'est ni celui de l’UID du fichier à déplacer, ni celui du répertoire le contenant, et le processus n'est pas privilégié (sous Linux\ : n'a pas la capacité \fBCAP_FOWNER\fP\ ; ou \fInewpath\fP est un fichier existant et le répertoire le contenant a son sticky bit positionné et l'UID effectif du processus n'est ni celui du fichier à déplacer, ni celui du répertoire le contenant, et le processus n'est pas privilégié (sous Linux\ : n'a pas la capacité \fBCAP_FOWNER\fP\ ; ou alors le système de fichiers contenant \fIpathname\fP ne permet pas le renommage du type demandé. .TP \fBEROFS\fP Le fichier se trouve sur un système de fichiers en lecture seule. .TP \fBEXDEV\fP \fIoldpath\fP et \fInewpath\fP ne sont pas sur le même système de fichiers monté. (Linux permet de monter un système de fichiers à plusieurs endroits, mais \fBrename\fP() ne fonctionne pas à travers des points de montage différents, même si le système de fichiers est monté sur les deux.) .PP Les erreurs supplémentaires suivantes peuvent également se produire pour \fBrenameat\fP() et \fBrenameat2\fP()\ : .TP \fBEBADF\fP \fIolddirfd\fP ou \fInewdirfd\fP n'est pas un descripteur de fichier valable. .TP \fBENOTDIR\fP \fIoldpath\fP est un chemin relatif, et \fIolddirfd\fP est un descripteur de fichier ne référençant pas un répertoire\ ; ou bien c'est le cas pour \fInewpath\fP et \fInewdirfd\fP. .PP Les erreurs supplémentaires suivantes peuvent également se produire pour \fBrenameat2\fP()\ : .TP \fBEEXIST\fP \fIflags\fP contient l'attribut \fBRENAME_NOREPLACE\fP et \fInewpath\fP existe déjà. .TP \fBEINVAL\fP \fIflags\fP contient un drapeau non valable. .TP \fBEINVAL\fP \fBRENAME_NOREPLACE\fP et \fBRENAME_EXCHANGE\fP sont tous les deux indiqués dans \fIflags\fP. .TP \fBEINVAL\fP \fBRENAME_WHITEOUT\fP et \fBRENAME_EXCHANGE\fP sont tous les deux indiqués dans \fIflags\fP. .TP \fBEINVAL\fP Le système de fichiers ne prend pas en charge l'un des attributs de \fIflags\fP. .TP \fBENOENT\fP \fIflags\fP contient \fBRENAME_EXCHANGE\fP et \fInewpath\fP n'existe pas. .TP \fBEPERM\fP \fBRENAME_WHITEOUT\fP est indiqué dans \fIflags\fP mais l'appelant n'a pas la capacité \fBCAP_MKNOD\fP. .SH VERSIONS \fBrenameat\fP() a été ajouté au noyau Linux dans sa version 2.6.16\ ; la glibc le gère depuis la version\ 2.4. .PP \fBrenameat2\fP() a été ajouté au noyau Linux dans sa version\ 3.15\ ; la glibc le gère depuis la version\ 2.28. .SH CONFORMITÉ \fBrename\fP()\ : 4.3BSD, C89, C99, POSIX.1\-2001, POSIX.1\-2008. .PP \fBrenameat\fP()\ : POSIX.1\-2008. .PP \fBrenameat2\fP() est spécifique à Linux. .SH NOTES .\" .SS "Notes de la glibc" Dans les anciens noyaux où \fBrenameat\fP() n’est pas disponible, les fonctions d’enveloppe de la glibc renvoient à l’utilisation de \fBrename\fP(). Quand \fIoldpath\fP et \fInewpath\fP sont des noms de chemin relatif, la glibc construit les noms de chemin basés sur les liens symboliques dans \fI/proc/self/fd\fP qui correspondent aux arguments \fIolddirfd\fP et \fInewdirfd\fP. .SH BOGUES Sur les systèmes de fichiers NFS, ce n'est pas parce que l'opération a échoué que le fichier n'a pas été renommé. Si le serveur effectue le renommage et se plante, la RPC transmise qui sera traitée lorsque le serveur sera à nouveau en état va entrainer un échec. L'application doit gérer ce genre de problème. Consultez \fBlink\fP(2) pour un problème similaire. .SH "VOIR AUSSI" \fBmv\fP(1), \fBchmod\fP(2), \fBlink\fP(2), \fBsymlink\fP(2), \fBunlink\fP(2), \fBpath_resolution\fP(7), \fBsymlink\fP(7) .SH COLOPHON Cette page fait partie de la publication\ 5.04 du projet \fIman\-pages\fP 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/. .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot , Frédéric Hantrais et Jean-Paul Guillonneau . Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE 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 à .MT debian-l10n-french@lists.debian.org .ME .