.\" -*- coding: UTF-8 -*- .\" Copyright, the authors of the Linux man-pages project .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH rename 2 "17 maja 2025 r." "Linux man\-pages 6.15" .SH NAZWA rename, renameat, renameat2 \- zmienia nazwę lub położenie pliku .SH BIBLIOTEKA Standardowa biblioteka C (\fIlibc\fP,\ \fI\-lc\fP) .SH SKŁADNIA .nf \fB#include \fP .P \fBint rename(const char *\fP\fIoldpath\fP\fB, const char *\fP\fInewpath\fP\fB);\fP .P \fB#include \fP/* Definicja stałych \fBAT_*\fP */ \fB#include \fP .P \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 \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 .P .RS -4 Wymagane ustawienia makr biblioteki glibc (patrz \fBfeature_test_macros\fP(7)): .RE .P .nf \fBrenameat\fP(): Od glibc 2.10: _POSIX_C_SOURCE >= 200809L Przed glibc 2.10: _ATFILE_SOURCE .P \fBrenameat2\fP(): _GNU_SOURCE .fi .SH OPIS \fBrename\fP() zmienia nazwę pliku, przenosząc go pomiędzy katalogami, jeśli to konieczne. Nie wpływa to na wszelkie inne zwykłe (twarde) dowiązania do pliku (jak utworzone przez \fBlink\fP(2)). Nie ma wpływu również na deskryptory pliku otwartego na \fIoldpath\fP. .P Na to, czy operacja zmiany nazwy się powiedzie, wpływa wiele ograniczeń: zob. BŁĘDY niżej. .P Jeśli \fInewpath\fP już istnieje, zostanie zastąpiona w sposób niepodzielny tak, że w żadnym momencie, gdy inny proces spróbuje uzyskać dostęp do \fInewpath\fP, nie zastanie jej nieistniejącej. Jednak prawdopodobnie wystąpi okno czasowe, w którym \fIoldpath\fP i \fInewpath\fP będą odnosić się do przemianowywanego pliku. .P Jeśli \fIoldpath\fP i \fInewpath\fP są istniejącymi dowiązaniami zwykłymi (twardymi), odnoszącymi się do tego pliku, to \fBrename\fP() nic nie robi i zwraca status powodzenia. .P Jeśli \fInewpath\fP istnieje, lecz operacja z jakiegoś powodu się nie powiedzie, \fBrename\fP() daje gwarancję pozostawienia wystąpienia \fInewpath\fP bez zmian. .P \fIoldpath\fP może określać katalog. W tym przypadku, \fInewpath\fP musi albo nie istnieć, albo musi określać pusty katalog. .P Jeśli \fIoldpath\fP odnosi się do dowiązania symbolicznego, dowiązaniu temu zostanie zmieniona nazwa; jeśli \fInewpath\fP odnosi się do dowiązania symbolicznego, dowiązanie zostanie nadpisane. .SS renameat() Wywołanie systemowe \fBrenameat\fP() operuje w dokładnie taki sam sposób jak \fBrename\fP(), z wyjątkiem różnic opisanych tutaj. .P Jeśli ścieżka podana w \fIoldpath\fP jest względna, jest to interpretowane w odniesieniu do katalogu do którego odnosi się deskryptor pliku \fIolddirfd\fP (zamiast w odniesieniu do bieżącego katalogu roboczego procesu wywołującego, jak w stosunku do ścieżek względnych robi to \fBrename\fP()). .P Jeśli \fIoldpath\fP jest względna a \fIolddirfd\fP ma wartość specjalną \fBAT_FDCWD\fP, to \fIoldpath\fP jest interpretowana w odniesieniu do bieżącego katalogu roboczego procesu wywołującego (jak \fBrename\fP()). .P Jeśli \fIoldpath\fP jest bezwzględna, to \fIolddirfd\fP jest ignorowane. .P Interpretacja \fInewpath\fP jest taka sama jak \fIoldpath\fP, z tym wyjątkiem, że ścieżka względna jest interpretowana względem katalogu, do którego odnosi się deskryptor pliku \fInewdirfd\fP. .P Więcej informacji o potrzebie wprowadzenia \fBrenameat\fP() można znaleźć w podręczniku \fBopenat\fP(2). .SS renameat2() \fBrenameat2\fP() ma dodatkowy argument \fIflags\fP. Wywołanie \fBrenameat2\fP() z zerowym argumentem \fIflags\fP jest równoważne \fBrenameat\fP(). .P Argument \fIflags\fP jest maską bitową składającą się z zera lub więcej następujących znaczników: .TP \fBRENAME_EXCHANGE\fP Niepodzielnie wymienia \fIoldpath\fP i \fInewpath\fP. Obie ścieżki muszą istnieć, lecz mogą być różnego typu (np. jedna może być niepustym katalogiem, a druga dowiązaniem symbolicznym). .TP \fBRENAME_NOREPLACE\fP Nie nadpisuje \fInewpath\fP przy zmianie nazwy. Zwraca błąd, gdy \fInewpath\fP już istnieje. .IP \fBRENAME_NOREPLACE\fP nie można łączyć z \fBRENAME_EXCHANGE\fP. .IP \fBRENAME_NOREPLACE\fP wymaga obsługi w systemie plików. Pojawiała się ona zgodnie z poniższym wykazem: .RS .IP \[bu] 3 .\" ext4: commit 0a7c3937a1f23f8cb5fc77ae01661e9968a51d0c ext4 (Linux 3.15); .IP \[bu] btrfs, tmpfs i cifs (Linux 3.17); .IP \[bu] .\" btrfs: commit 80ace85c915d0f41016f82917218997b72431258 .\" tmpfs: commit 3b69ff51d087d265aa4af3a532fc4f20bf33e718 .\" cifs: commit 7c33d5972ce382bcc506d16235f1e9b7d22cbef8 .\" .\" gfs2 in Linux 4.2? xfs (Linux 4.0); .IP \[bu] .\" Also affs, bfs, exofs, hfs, hfsplus, jffs2, logfs, msdos, .\" nilfs2, omfs, sysvfs, ubifs, udf, ufs .\" hugetlbfs, ramfs .\" local filesystems: commit f03b8ad8d38634d13e802165cc15917481b47835 .\" libfs: commit e0e0be8a835520e2f7c89f214dfda570922a1b90 Obsługę wielu innych systemów plików dodano w Linuksie 4.9, w tym ext2, minix, reiserfs, jfs, vfat i bpf. .RE .TP \fBRENAME_WHITEOUT\fP (od Linuksa 3.18) .\" commit 0d7a855526dd672e114aff2ac22b60fc6f155b08 .\" commit 787fb6bc9682ec7c05fb5d9561b57100fbc1cc41 Operacja ta ma sens tylko w implementacjach systemu plików typu nakładka/unia (overlay/union). .IP Podanie \fBRENAME_WHITEOUT\fP tworzy obiekt \[Bq]zaciemniający\[rq] w miejscu źródła zmiany nazwy w momencie dokonywania zmiany nazwy. Cała operacja jest niepodzielna, tak więc jeśli zmiana nazwy się powiedzie, to utworzone zostanie również zaciemnienie. .IP Obiekt \[Bq]zaciemniający\[rq] ma specjalne znaczenie w systemach plików typu nakładka/unia. Istnieje tam wiele warstw i jedyną, która jest kiedykolwiek modyfikowana, jest najwyższa. Zaciemnienie na wyższej warstwie, efektywnie ukrywa odpowiedni plik w niższej warstwie, dając wrażenie, że plik nie istnieje. .IP Jeśli plikowi istniejącemu w niższej warstwie zmieniana jest nazwa, plik jest najpierw kopiowany w górę (jeśli nie jest jeszcze na wyższej warstwie), a następnie zmieniana jest mu nazwa na wyższej warstwie, będącej do odczytu i zapisu. W tym samym czasie plik źródłowy musi być \[Bq]zaciemniony\[rq] (dzięki czemu wersja pliku źródłowego w niższej warstwie staje się niewidoczna). Cała operacja musi być niepodzielna. .IP .\" https://www.freebsd.org/cgi/man.cgi?query=mount_unionfs&manpath=FreeBSD+11.0-RELEASE Gdy nie jest częścią nakładki/unii, zaciemnienie jest widoczne jako urządzenie znakowe z numerem urządzenia {0,0} (proszę zauważyć, że inne implementacje nakładki/unii mogą używać odmiennych metod do przechowywania zaciemnionych wpisów; w szczególności, unie BSD korzystają z oddzielnego typu i\-węzła, który, choć obsługiwany przez niektóre systemy plików dostępne w Linuksie, takie jak CODA i XFS, jest ignorowany przez zaciemniający kod jądra, przynajmniej według stanu na Linuksa 4.19). .IP \fBRENAME_WHITEOUT\fP wymaga tych samym przywilejów, co utworzenie węzła urządzenia (tj. przywileju \fBCAP_MKNOD\fP). .IP \fBRENAME_WHITEOUT\fP nie można łączyć z \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 musi być obsługiwane przez przedmiotowy system plików. Pośród obsługujących systemów plików są: tmpfs (od Linuksa 3.18), ext4 (od Linuksa 3.18), XFS (od Linuksa 4.1), f2fs (od Linuksa 4.2), btrfs (od Linuksa 4.7) oraz ubifs (od Linuksa 4.9). .SH "WARTOŚĆ ZWRACANA" Po pomyślnym zakończeniu zwracane jest zero. Po błędzie zwracane jest \-1 i ustawiane \fIerrno\fP, wskazując błąd. .SH BŁĘDY .TP \fBEACCES\fP Odmówiono uprawnienia zapisu dla katalogu zawierającego \fIoldpath\fP lub \fInewpath\fP; albo odmówiono uprawnienia przeszukiwania dla jednego z katalogów w przedrostku ścieżki \fIoldpath\fP lub \fInewpath\fP; albo \fIoldpath\fP jest katalogiem i nie zezwala na uprawnienie zapisu (potrzebne do zaktualizowania wpisu \fI..\fP). Zob. też \fBpath_resolution\fP(7). .TP \fBEBUSY\fP Zmiana nazwy nie powiodła się, ponieważ \fIoldpath\fP lub \fInewpath\fP jest katalogiem, który jest używany przez jakiś proces (być może jako bieżący katalog roboczy albo katalog główny, albo ponieważ był otwarty do odczytu) lub jest używany przez system (np. jako punkt montowania), a system uważa to za błąd (proszę zauważyć, że nie ma obowiązku zwracania w takim przypadku \fBEBUSY\fP \[em] nie ma niczego złego w dokonaniu wówczas zmiany nazwy \[em] lecz można zwrócić \fBEBUSY\fP, jeśli system nie może jednak obsłużyć takich sytuacji). .TP \fBEDQUOT\fP Przydział bloków dyskowych użytkownika dotyczący systemu plików został wyczerpany. .TP \fBEFAULT\fP \fIoldpath\fP lub \fInewpath\fP wskazuje poza dostępną dla użytkownika przestrzeń adresową. .TP \fBEINVAL\fP Nowa ścieżka zawierała przedrostek ścieżki starej lub, ogólniej, próbowano utworzyć katalog lub podkatalog siebie samego. .TP \fBEISDIR\fP \fInewpath\fP jest istniejącym katalogiem, lecz \fIoldpath\fP nie jest katalogiem. .TP \fBELOOP\fP Podczas rozwiązywania \fIoldpath\fP lub \fInewpath\fP napotkano zbyt wiele dowiązań symbolicznych. .TP \fBEMLINK\fP Do \fIoldpath\fP osiągnięto już maksymalną dowiązań lub był to katalog, a katalog zawierający \fInewpath\fP ma maksymalną liczbę dowiązań. .TP \fBENAMETOOLONG\fP \fIoldpath\fP lub \fInewpath\fP było zbyt długie. .TP \fBENOENT\fP Dowiązanie o nazwie \fIoldpath\fP nie istnieje; lub składowa katalogu w \fInewpath\fP nie istnieje; lub \fIoldpath\fP albo \fInewpath\fP jest łańcuchem pustym. .TP \fBENOMEM\fP Brak pamięci jądra. .TP \fBENOSPC\fP Na urządzeniu zawierającym plik nie ma miejsca na kolejny wpis w katalogu. .TP \fBENOTDIR\fP Składowa używana jako katalog w \fIoldpath\fP lub \fInewpath\fP nie jest faktycznie katalogiem; lub \fIoldpath\fP jest katalogiem, a \fInewpath\fP istnieje, lecz nie jest katalogiem. .TP \fBENOTEMPTY\fP lub \fBEEXIST\fP \fInewpath\fP jest niepustym katalogiem tj. zawiera wpisy inne niż \[Bq].\[rq] oraz \[Bq]..\[rq]. .TP \fBEPERM\fP lub \fBEACCES\fP Katalog zawierający \fIoldpath\fP ma ustawiony bit lepkości (\fBS_ISVTX\fP), a efektywny identyfikator użytkownika procesu nie jest ani identyfikatorem użytkownika usuwanego pliku, ani katalogu go zawierającego oraz proces nie jest uprzywilejowany (Linux: nie ma przywileju \fBCAP_FOWNER\fP); albo: \fInewpath\fP jest istniejącym plikiem, katalog go zawierający ma ustawiony bit lepkości, a efektywny identyfikator użytkownika procesu nie jest ani identyfikatorem użytkownika usuwanego pliku, ani katalogu go zawierającego oraz proces nie jest uprzywilejowany (Linux: nie ma przywileju \fBCAP_FOWNER\fP); albo: system plików zawierający \fIoldpath\fP nie obsługuje zmiany nazwy żądanego typu. .TP \fBEROFS\fP Plik leży w systemie plików tylko do odczytu. .TP \fBEXDEV\fP \fIoldpath\fP i \fInewpath\fP nie są położone w zamontowanym tak samo systemie plików (Linux zezwala na zamontowanie systemu plików w wielu punktach, ale \fBrename\fP() nie działa poprzez różne punkty montowania, nawet jeśli w obu zamontowany jest ten sam system plików). .P W przypadku \fBrenameat\fP() i \fBrenameat2\fP() mogą wystąpić następujące, dodatkowe błędy: .TP \fBEBADF\fP \fIoldpath\fP (\fInewpath\fP) jest względna, lecz \fIolddirfd\fP (\fInewdirfd\fP) nie jest prawidłowym deskryptorem pliku. .TP \fBENOTDIR\fP \fIoldpath\fP jest względna, a \fIolddirfd\fP jest deskryptorem pliku odnoszącym się do pliku innego niż katalog; lub analogicznie dla \fInewpath\fP i \fInewdirfd\fP .P Następujące dodatkowe błędy mogą wystąpić w przypadku \fBrenameat2\fP(): .TP \fBEEXIST\fP \fIflags\fP zawiera \fBRENAME_NOREPLACE\fP, a \fInewpath\fP już istnieje. .TP \fBEINVAL\fP We \fIflags\fP podano nieprawidłowy znacznik. .TP \fBEINVAL\fP We \fIflags\fP podano równocześnie \fBRENAME_NOREPLACE\fP i \fBRENAME_EXCHANGE\fP. .TP \fBEINVAL\fP We \fIflags\fP podano równocześnie \fBRENAME_WHITEOUT\fP i \fBRENAME_EXCHANGE\fP. .TP \fBEINVAL\fP System plików nie obsługuje jednego ze znaczników z \fIflags\fP. .TP \fBENOENT\fP \fIflags\fP zawiera \fBRENAME_EXCHANGE\fP, a \fInewpath\fP nie istnieje. .TP \fBEPERM\fP We \fIflags\fP podano \fBRENAME_WHITEOUT\fP, lecz wywołujący nie ma przywileju \fBCAP_MKNOD\fP. .SH STANDARDY .TP \fBrename\fP() C11, POSIX.1\-2008. .TP \fBrenameat\fP() POSIX.1\-2008. .TP \fBrenameat2\fP() Linux. .SH HISTORIA .TP \fBrename\fP() 4.3BSD, C89, POSIX.1\-2001. .TP \fBrenameat\fP() Linux 2.6.16, glibc 2.4. .TP \fBrenameat2\fP() Linux 3.15, glibc 2.28. .SS "Uwagi dla glibc" W starszych jądrach, gdzie \fBrenameat\fP() jest niedostępne, funkcja opakowująca korzysta zapasowo z \fBrename\fP(). Gdy \fIoldpath\fP i \fInewpath\fP są ścieżkami względnymi, glibc tworzy ścieżki w oparciu o dowiązania symboliczne w \fI/proc/self/fd\fP, które są związane z argumentami \fIolddirfd\fP i \fInewdirfd\fP. .SH USTERKI W systemach plików NFS nie można zakładać, że przy niepowodzeniu operacji, nazwa pliku nie uległa zmianie. Jeśli serwer dokonuje operacji zmiany nazwy, a następnie się załamie, ponowna transmisja RPC, która nastąpi po podniesieniu się serwera, spowoduje błąd. Oczekuje się, że aplikacje mają sobie z tym radzić. Podobny problem występuje w \fBlink\fP(2). .SH "ZOBACZ TAKŻE" \fBmv\fP(1), \fBrename\fP(1), \fBchmod\fP(2), \fBlink\fP(2), \fBsymlink\fP(2), \fBunlink\fP(2), \fBpath_resolution\fP(7), \fBsymlink\fP(7) .PP .SH TŁUMACZENIE Tłumaczenie niniejszej strony podręcznika: Michał Kułach . .PP Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License w wersji 3 .UE lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI. .PP Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej .MT manpages-pl-list@lists.sourceforge.net .ME .