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>           /* Definitie van AT_* constanten */
#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);
Feature Test Macro´s eisen 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 mappen 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).)
Het hernoemen faalde omdat oudpad of nieuwpad een map is die in gebruik is door een of ander proces (misschien als huidige werkmap, of als systeembeheerder map, of omdat het voor schrijven open was) of het is in gebruik door het systeem (bijvoorbeeld als aankoppel punt), en het systeem beschouwd dit als een fout. (Merk op dat er geen vereiste is om EBUSY terug te geven is in deze gevallen \mer is niets mis met het hoe-dan-ook doen van de hernoeming\m maar het wordt toegestaan om EBUSY terug te geven als het systeem dergelijke situaties niet anders kan afhandelen.)
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 "..".
De map die oudpad bevat heeft het plak-bit (S_ISVTX) gezet enhet effectieve gebruiker ID is noch het gebruiker ID van het bestand dat gewist moet worden noch dat van de map die het bevat, en het proces is niet gerechtigd (Linux: heeft de CAP_FOWNER capaciteit); of nieuwpad is een bestaand bestand en de map die het bevat heeft het plak-bit gezet en het effectieve gebruiker ID van het proces is noch het gebruiker ID van het bestand dat moet worden vervangen noch dat van de map die het bevat, en het proces is niet gerechtigd (Linux: heeft de CAP_FOWNER capaciteit niet); of het bestandssysteem dat oudpad bevat ondersteund het hernoemen van het dit type niet.
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():

oudemapbi (nieuwpad) is relatief maar oudemapbi (nieuwmapbi) is geen geldige bestandsindicator.
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