RENAME(2) Linux Programmeurs Handleiding RENAME(2)

rename, renameat, renameat2 - verander de naam of plaats van een bestand

#include <stdio.h>
int rename(const char *oudpad, const char *nieuwpad);
#include <fcntl.h>           /* Definition of AT_* constants */
#include <stdio.h>
int renameat(int oud_bes_ind, const char *oudpad,
             int nieuw_bes_ind, const char *nieuwpad);
int renameat2(int oud_bes_ind, const char *oudpad,
              int nieuw_bes_ind, const char *nieuwpad, unsigned int vlaggen);
Test Macro´s in glibc (zie feature_test_macros(7)):
renameat():

Vanaf glibc 2.10:
_POSIX_C_SOURCE >= 200809L
Voor glibc 2.10:
_ATFILE_SOURCE
renameat2():

_GNU_SOURCE

rename() hernoemt een bestand, het naar andere directories verplaatsend als nodig. Elke andere harde koppeling naar het bestand (gemaakt met link(2)) blijft onaangetast. Open bestandsindicatoren voor oudpad blijven ook onaangetast.

Diverse beperkingen bepalen of de rename operatie wel of niet succesvol is: zie FOUTEN hieronder.

Als nieuwpad al bestaat wordt het atomair vervangen zodat er geen enkel moment is waarop een ander proces dat toegang tot nieuwpad probeert te krijgen het zal missen. Hoewel er mogelijk een venster kan zijn waarin beiden oudpad en nieuwpad naar het bestand wijzen dat hernoemd wordt.

Als oudpad en nieuwpad bestaande harde verwijzingen naar hetzelfde bestand zijn, dan doet rename() niks en geeft een succes status terug.

Als nieuwpad bestaat maar de handeling faalt om een of andere reden, dan garandeert rename(), nieuwpad op zijn plaats te laten.

oudpad kan een map specificeren. In dit geval moet of nieuwpad niet bestaan of een lege map specificeren.

Als oudpad naar een symbolische link wijst, wordt de koppeling hernoemd; als nieuwpad naar een symbolische link wijst wordt de koppeling overschreven.

De renameat() systeem aanroep werkt op exact dezelfde manier a;ls rename(), behalve voor de hier beschreven verschillen.

Als de padnaam gegeven in oudpad relatief is, dan wordt deze geïnterpreteerd als relatief ten opzichte van de map aangewezen door de bestandsindicator oud_bes_ind (in plaats van relatief aan de werkmap van het aanroepende proces, zoals gedaan door rename() voor een relatieve padnaam).

Als oudpad relatief is en oud_bes_ind de speciale waarde AT_FDCWD heeft, dan wordt oudpad geïnterpreteerd als relatief aan de werkmap van het aanroepende proces (zoals rename()).

Als oudpad absoluut is, dan wordt oudpadbi genegeerd.

De interpretatie van nieuwpad is zoals voor oudpad behalve dat een relatieve padnaam wordt geïnterpreteerd als relatief aan de map aangewezen door de bestandsindicator nieuwmapbi.

Zie openat(2) voor een uitleg over de noodzaak van renameat().

renameat2() heeft een additioneel vlaggen argument. Een renameat2() aanroep met een nul vlaggen argument is equivalent met renameat().

Het vlaggen argument is een bit masker bestaande uit nul of meer van de volgende vlaggen:

Verwissel oudpad en nieuwpad atomair. Beide padnamen moeten bestaan maar mogen van verschillende typen zijn (b.v. een zou een niet-lege map kunnen zijn en de andere een symbolische verwijzing).
Overschrijf nieuwpad niet bij het hernoemen. Geef een fout terug als nieuwpad al bestaat.
RENAME_NOREPLACE kan niet gebruikt worden samen met RENAME_EXCHANGE.
RENAME_NOREPLACE vereist ondersteuning door het onderliggende bestandssysteem. Ondersteuning door verschillende bestandssystemen wordt als volgt toegevoegd:
  • ext4 (Linux 3.15);
  • btrfs, tmpfs, en cifs (Linux 3.17);
  • xfs (Linux 4.0);
  • Ondersteuning voor veel andere bestandssystemen werd toegevoegd in Linux 4.9, inclusief ext2, minix, reiserfs, jfs, vfat en bpf.
Deze operatie is alleen logisch voor overlappende/eenheid bestandssysteem implementaties.
Opgeven van RENAME_WHITEOUT creëert een "whiteout" object aan het begin van het hernoemen op hetzelfde tijdstip als het uitvoeren van het hernoemen. De hele operatie is atomair, zodat als het hernoemen succesvol is de "whiteout" ook zal zijn aangemaakt.
Een "whiteout" is een object met een speciale betekenis in eenheid/overlap bestandssysteem constructies. In deze constructies, bestaan meerdere lagen en alleen de bovenste zal ooit worden gewijzigd. Een "whiteout" op een bovenste laag zal een overeenkomend bestand effectief verstoppen in een lagere laag, er voor zorgende dat het bestand verschijnt alsof het niet bestaat.
Wanneer een bestaand bestand op de lagere laag werd hernoemd, dan wordt deze allereerst omhoog gekopieerd (als hij al niet bestond op de hogere laag) en vervolgens gehernoemd op de hogere, lees-schrijf laag. Tegelijkertijd moet het bron bestand ge-"whiteout" zijn (zodat de versie van het bron bestand in de lagere laag onzichtbaar is). De gehele operatie dient atomair uitgevoerd te worden.
Indien geen onderdeel van een eenheid/overlap, dan verschijnt de "whiteout" als een teken apparaat met (0,0) als apparaat nummer. (Merk op dan andere eenheid/overlap implementaties andere methodes kunnen gebruiken om "whiteout" eenheden op te slaan; zo gebruikt de BSD eenheid koppeling het speciale inode type DT_WHT die, hoewel ondersteund door een aantal bestandssystemen beschikbaar in Linux, zoals CODA en XFS, wordt genegeerd door de ondersteunende code in de kernel, vanaf Linux 4.19.)
RENAME_WHITEOUT vereist dezelfde rechten als voor het aanmaken van een apparaat node (m.a.w, de CAP_MKNOD capaciteit).
RENAME_NOREPLACE kan niet gebruikt worden samen met RENAME_EXCHANGE.
RENAME_NOREPLACE vereist ondersteuning door het onderliggende bestandssysteem. Onder de bestandssystemen die het ondersteunen zijn tmpfs (vanaf Linux 3.18), ext4 (vanaf Linux 3.18), XFS (vanaf Linux 4.1), f2fs (vanaf Linux 4.2), btrfs (vanaf Linux 4.7), en ubifs (vanaf Linux 4.9).

Bij succes wordt nul teruggegeven. Bij falen wordt -1 teruggegeven en wordt errno overeenkomstig gezet.

Schrijf toegang is niet toegestaan in de map die oudpad of nieuwpad bevat, of, zoeken is niet toegestaan voor een van de mappen in het pad voorvoegsel van oudpad of nieuwpad, of oudpad is een map en staat niet schrijftoestemming niet toe (die nodig is om de .. ingang te updaten). (Zie ook path_resolution(7).)
The rename fails because oldpath or newpath is a directory that is in use by some process (perhaps as current working directory, or as root directory, or because it was open for reading) or is in use by the system (for example as a mount point), while the system considers this an error. (Note that there is no requirement to return EBUSY in such cases—there is nothing wrong with doing the rename anyway—but it is allowed to return EBUSY if the system cannot otherwise handle such situations.)
De gebruiker quota van schijf blokken op het bestandssysteem zijn uitgeput.
oudpad of nieuwpad wijzen buiten door u toegankelijke adres ruimte.
De nieuwe padnaam bevat een voorvoegsel van de oude, of, algemener, een poging werd gedaan om een map een ondermap van zichzelf te maken.
nieuwpad is een bestaande map, maar oudpad is geen map.
Teveel symbolische koppelingen werden tegengekomen bij het vaststellen van oudpad of nieuwpad.
oudpad heeft al het maximum aantal koppelingen naar zich toe, of het was een dir en de map die nieuwpad bevat heeft al het maximum aantal koppelingen.
oudpad of nieuwpad was te lang.
De verwijzing aangeduid door oudpad bestaat niet of een map component in nieuwpad bestaat niet, of oudpad of nieuwpad zijn lege tekenreeksen.
Onvoldoende kernelgeheugen voorhanden.
Het apparaat waar het bestand op zit heeft geen ruimte voor een nieuwe map.
Een deel gebruikt als een map in oudpad of nieuwpad is in feite geen map. Of, oudpad is een map, en nieuwpad bestaat maar is geen map.
nieuwpad is een niet-lege map, het bevat andere ingangen dan "." en "..".
The directory containing oldpath has the sticky bit (S_ISVTX) set and the process's effective user ID is neither the user ID of the file to be deleted nor that of the directory containing it, and the process is not privileged (Linux: does not have the CAP_FOWNER capability); or newpath is an existing file and the directory containing it has the sticky bit set and the process's effective user ID is neither the user ID of the file to be replaced nor that of the directory containing it, and the process is not privileged (Linux: does not have the CAP_FOWNER capability); or the filesystem containing oldpath does not support renaming of the type requested.
Het bestand staat op een alleen-lezen bestandssysteem.
oudpad en nieuwpad zitten niet op hetzelfde aangekoppelde bestandssysteem. (Linux staat toe dat bestandssystemen worden aangekoppeld op meerdere punten, maar rename() werkt niet over verschillende aankoppel punten, zelfs als hetzelfde bestandssysteem is gekoppeld op beiden.)

De volgende extra fouten kunnen optreden voor renameat() en renameat2():

oldpath (newpath) is relative but olddirfd (newdirfd) is not a valid file descriptor.
oudpad is relatief en oudmapbi is een bestandsindicator die naar een bestand anders dan een map wijst; of vergelijkbaar voor nieuwpad en nieuwmapbi

De volgende extra fouten kunnen optreden voor renameat2():

vlaggen bevat RENAME_NOREPLACE en nieuwpad bestaat al.
Een ongeldig vlag werd in vlaggen opgegeven.
Zowel RENAME_NOREPLACE als RENAME_EXCHANGE werden opgegeven in vlaggen.
Zowel RENAME_NOREPLACE als RENAME_EXCHANGE werden opgegeven in vlaggen.
Het bestandssysteem ondersteund een van de vlaggen in vlaggen niet.
flags bevat RENAME_EXCHANGE en nieuwpad bestaat niet.
RENAME_WHITEOUT werd opgegeven in vlaggen, maar de aanroeper heeft deCAP_MKNOD capaciteit niet.

renameat() werd toegevoegd aan Linux in kernel 2.6.16; bibliotheek ondersteuning werd toegevoegd aan glibc in versie 2.4.

renameat2() werd toegevoegd aan Linux in kernel 3.15; bibliotheek ondersteuning werd toegevoegd aan glibc in versie 2.28.

rename(): 4.3BSD, C89, C99, POSIX.1-2001, POSIX.1-2008.

renameat(): POSIX.1-2008.

renameat2() is Linux-eigen.

Op oudere kernels waar renameat() niet beschikbaar is, valt de glibc omwikkelfunctie terug op het gebruik van rename(). Als oudpad and nieuwpad relative padnamen zijn, dan zal glibc padnamen construeren gebaseerd op de symbolische koppelingen in /proc/self/fd die overeenkomen met de oudmapbi en nieuwmapbi argumenten.

Op NFS bestandsystemen kun je niet aannemen dat als een handeling mislukte, het bestand niet hernoemd werd. Als de server de hernoem-handeling doet en gecrasht dan zal de herverstuurde RPC die afgehandeld zal worden als de server het weer doet, een fout veroorzaken. Van toepassing wordt verwacht hiermee om te gaan. Zie link(2) voor gelijksoortige problemen.

mv(1), rename(1), chmod(2), link(2), symlink(2), unlink(2), path_resolution(7), symlink(7)

Deze pagina is onderdeel van release 5.13 van het Linux man-pages-project. Een beschrijving van het project, informatie over het melden van bugs en de nieuwste versie van deze pagina zijn op https://www.kernel.org/doc/man-pages/ te vinden.

De Nederlandse vertaling van deze handleiding is geschreven door Jos Boersema <joshb@xs4all.nl>, Mario Blättermann <mario.blaettermann@gmail.com> en Luc Castermans <luc.castermans@gmail.com>

Deze vertaling is vrije documentatie; lees de GNU General Public License Version 3 of later over de Copyright-voorwaarden. Er is geen AANSPRAKELIJKHEID.

Indien U fouten in de vertaling van deze handleiding zou vinden, stuur een e-mail naar debian-l10n-dutch@lists.debian.org.

27 augustus 2021 Linux