.\" -*- coding: UTF-8 -*- .\" Copyright 1992-1994, The Regents of the University of California. .\" Copyright 2008-2014, Michael Kerrisk .\" Copyright, the authors of the Linux man-pages project .\" .\" SPDX-License-Identifier: BSD-3-Clause .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH symlink 7 "8 lutego 2026 r." "Linux man\-pages 6.18" .SH NAZWA symlink \- obsługa dowiązań symbolicznych .SH OPIS Dowiązania symboliczne są plikami, które działają jak wskaźniki do innych plików. Aby zrozumieć ich działanie, konieczne jest wcześniejsze poznanie mechanizmu działania dowiązań zwykłych. .P Dowiązanie zwykłe do pliku jest nierozróżnialne od pierwotnego pliku, ponieważ jest odniesieniem do samego obiektu, do którego odnosi się pierwotna nazwa pliku (precyzyjniej: każde z dowiązań zwykłych do pliku odnosi się do tego samego \fInumeru i\-węzła\fP: gdzie numer i\-węzła jest numerem indeksu w tablicy i\-węzłów, zawierającej metadane o wszystkich plikach w systemie plików. Zob. \fBstat\fP(2)). Zmiany w pliku są niezależne od nazwy, jaka odnosi się do pliku. Dowiązania zwykłe nie odnoszą się do katalogów (aby uniemożliwić wystąpienie pętli w drzewie systemu plików, które zmyliłyby wiele programów) i nie mogą odnosić się do plików w innych systemach plików (ponieważ numery i\-węzłów nie są unikalne pomiędzy systemami plików). .P Dowiązanie symboliczne jest specjalnym typem pliku, którego zawartość jest łańcuchem, będącym ścieżką innego pliku \[em] pliku na który wskazuje dowiązanie (zawartość dowiązania symbolicznego można odczytać za pomocą \fBreadlink\fP(2)). Innymi słowy, dowiązanie symboliczne jest wskaźnikiem do innej nazwy, a nie do samego obiektu. Z tego powodu, dowiązania symboliczne mogą odnosić się do katalogów i mogą przekraczać granice systemu plików. .P Nie ma wymagania aby ścieżka, do której odnosi się dowiązanie symboliczne, musiała istnieć. Dowiązanie symboliczne odnoszące się do nieistniejącej ścieżki jest nazywane \fIdowiązaniem wiszącym\fP. .P .\" Dowiązanie symboliczne i obiekt, do którego się odnosi, istnieją jednocześnie w przestrzeni nazw systemu plików, zatem może dojść do problemów w rozróżnieniu samego dowiązania i obiektu na który ono wskazuje. W dawnych systemach, polecenia i wywołania systemowe zaadoptowały swoje własne, dość przypadkowe konwencje, dotyczące podążania za dowiązaniami. Tutaj opisano nieco bardziej spójne podejście, opisujące sposób implementacji w systemie Linux i innych. Jest ważne, aby lokalne aplikacje w systemie również przestrzegały tych reguł tak, aby interfejs użytkownika był jak najbardziej spójny. .SS "Dowiązania magiczne" Istnieje specjalna klasa obiektów dowiązaniopodobnych\[tm] zwanych \[Bq]dowiązaniami magicznymi\[rq], które występują w określonych pseudosystemach plików, takich jak \fBproc\fP(5) (np. \fI/proc/\fPpid\fI/exe\fP i \fI/proc/\fPpid\fI/fd/\fP*). W przeciwieństwie do standardowych dowiązań symbolicznych, dowiązania magiczne nie są rozwiązywane za pomocą podążania za ścieżką, lecz są bezpośrednimi odniesieniami do własnych reprezentacji jądra wobec uchwytów plików. Jako takie, dowiązania magiczne umożliwiają użytkownikom dostęp do plików, do których nie mogą odnosić się zwykłe ścieżki (np. do odlinkowanych plików, do których wciąż odnosi się działający program). .P .\" Dowiązania magiczne mogą pomijać standardowe ograniczenia wynikające z przestrzeni nazw montowań (\fBmount_namespaces\fP(7)), dlatego były już wektorem ataków stosowanym przez różne exploity. .SS "Własności, uprawnienia i znaczniki czasowe dowiązań symbolicznych" Właściciela i grupę istniejącego dowiązania symbolicznego można zmienić za pomocą \fBlchown\fP(2). Własność dowiązania symbolicznego ma znaczenie, gdy dowiązanie jest usuwane lub zmieniane w katalogu, który ma ustawiony bit lepkości (zob. \fBinode\fP(7)) oraz gdy ustawiona jest kontrolka systemowa \fIfs.protected_symlinks\fP (zob. \fBproc\fP(5)). .P Znaczniki czasowe ostatniego dostępu i ostatniej modyfikacji dowiązania symbolicznego można zmienić za pomocą \fButimensat\fP(2) lub \fBlutimes\fP(3). .P .\" Linux does not currently implement an lchmod(2). W Linuksie, uprawnienia standardowego dowiązania symbolicznego nie są używane przy żadnych operacjach; uprawnienia są ustawione zawsze na 0777 (odczyt, zapis i wykonanie dla wszystkich kategorii użytkowników) i nie mogą być zmieniane. .P .\" .P .\" The .\" 4.4BSD .\" system differs from historical .\" 4BSD .\" systems in that the system call .\" .BR chown (2) .\" has been changed to follow symbolic links. .\" The .\" .BR lchown (2) .\" system call was added later when the limitations of the new .\" .BR chown (2) .\" became apparent. Dowiązania magiczne nie przestrzegają jednak tej reguły. Mogą mieć tryb inny niż 0777, choć nie jest to obecnie używane przy żadnych sprawdzeniach uprawnień. .SS "Pozyskiwanie deskryptora pliku odnoszącego się do dowiązania symbolicznego" Łącząc w \fBopen\fP(2) znaczniki \fBO_PATH\fP i \fBO_NOFOLLOW\fP można uzyskać deskryptor pliku, które można przekazać jako argument \fIdirfd\fP wywołaniom systemowym, takim jak: \fBfstatat\fP(2), \fBfchownat\fP(2), \fBfchmodat\fP(2), \fBlinkat\fP(2) i \fBreadlinkat\fP(2), aby działać na samym dowiązaniu symbolicznym (a nie na pliku, do którego się ono odnosi). .P Domyślnie (tj. bez znacznika \fBAT_SYMLINK_FOLLOW\fP) jeśli do dowiązania symbolicznego zastosuje się \fBname_to_handle_at\fP(2), to zwróci ono uchwyt do dowiązania symbolicznego (a nie pliku, do którego się ono odnosi). Można następnie uzyskać deskryptor pliku samego dowiązania symbolicznego (a nie pliku, do którego się ono odnosi), podając znacznik \fBO_PATH\fP w kolejnym wywołaniu do \fBopen_by_handle_at\fP(2). Ten deskryptor pliku można użyć w opisanych wcześniej wywołaniach systemowych, aby działać na samym dowiązaniu symbolicznym. .SS "Obsługa dowiązań symbolicznych przez polecenia i wywołania systemowe" Działania wobec dowiązań symbolicznych są dokonywane albo na samym dowiązaniu, albo na obiekcie, do którego odnosi się dowiązanie. W tym drugim przypadku mówi się, że aplikacja lub wywołanie systemowe \fIpodąża\fP za dowiązaniem. Dowiązania symboliczne może odnosić się do kolejnych dowiązań symbolicznych; wówczas dowiązania są rozwiązywane do momentu: odnalezienia obiektu niebędącego dowiązaniem symbolicznym, odnalezienia dowiązania symbolicznego odnoszącego się do nieistniejącego pliku albo wykrycia pętli (pętle są wykrywane poprzez nałożenie górnego limitu na kolejne podążanie za dowiązaniami i wystąpieniu błędu po jego przekroczeniu). .P Konieczne jest omówienie trzech odrębnych przypadków. Oto one: .IP \[bu] 3 Dowiązania symboliczne będące argumentami do wywołań systemowych. .IP \[bu] Dowiązania symboliczne będące argumentami wiersza poleceń do narzędzi, które nie przechodzą przez drzewo plików. .IP \[bu] Dowiązania symboliczne, na które napotkają narzędzia przechodzące przez drzewo plików (albo podane w wierszu poleceń, albo napotkane przy przechodzeniu przez drzewo plików). .P .\" Przed opisem traktowania dowiązań symbolicznych przez polecenia i wywołania systemowe, konieczne będzie zdefiniowanie pewnych pojęć. Zakładając, że ścieżka ma postać \fIa/b/c\fP, część poprzedzająca ostatni ukośnik (tj. \fIa/b\fP) jest nazywana składową \fIdirname\fP (katalogową), a część po ostatnim ukośniku (tj. \fIc\fP) jest nazywana składową \fIbasename\fP (podstawową). .SS "Traktowanie dowiązań symbolicznych w wywołaniach systemowych" Pierwszy przypadek dotyczy dowiązań symbolicznych, użytych jako argumenty z nazwą pliku w wywołaniach systemowych. .P Dowiązania symboliczne w ścieżce przekazywanej do wywołania systemowego są traktowane następująco: .IP (1) 5 W składowej dirname (katalogowej) ścieżki, podąża się za dowiązaniami symbolicznymi zawsze, w niemal każdym wywołaniu systemowym (jest to prawdziwe również dla poleceń). Jedynym wyjątkiem jest \fBopenat2\fP(2), które udostępnia znaczniki, mogące być użyte do wyłączenia podążania za dowiązaniami symbolicznymi w składowej dirname (katalogowej). .IP (2) Poza wyjątkami opisanymi poniżej, wszystkie wywołania systemowe podążają za dowiązaniami symbolicznymi w składowej basename (podstawowej) ścieżki. Przykładowo, jeśli istniałoby dowiązanie symboliczne \fIslink\fP wskazujące na plik o nazwie \fIafile\fP, to wywołanie systemowe \fIopen("slink" \&...\&)\fP zwróciłoby deskryptor pliku odnoszący się do pliku \fIafile\fP. .P Istnieją wywołania systemowe, które nie podążają za dowiązaniami w składowej basename (podstawowej) ścieżki, lecz działają na samym dowiązaniu symbolicznym. Są to: \fBlchown\fP(2), \fBlgetxattr\fP(2), \fBllistxattr\fP(2), \fBlremovexattr\fP(2), \fBlsetxattr\fP(2), \fBlstat\fP(2), \fBreadlink\fP(2), \fBrename\fP(2), \fBrmdir\fP(2) oraz \fBunlink\fP(2). .P .\" Maybe one day: .BR fchownat (2) Pewne inne wywołania systemowe opcjonalnie podążają za dowiązaniami symbolicznymi w składowej basename (podstawowej) ścieżki. Są to: \fBfaccessat\fP(2), \fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2), \fBname_to_handle_at\fP(2), \fBopen\fP(2), \fBopenat\fP(2), \fBopen_by_handle_at\fP(2) i \fButimensat\fP(2); więcej szczegółów w innych podręcznikach systemowych. Jako że \fBremove\fP(3) jest aliasem \fBunlink\fP(2), ta funkcja biblioteczna nie podąża za dowiązaniami symbolicznymi. Gdy do dowiązania symbolicznego zastosuje się \fBrmdir\fP(2), to wywołanie zawiedzie z błędem \fBENOTDIR\fP. .P \fBlink\fP(2) zasługuje na odrębny opis. POSIX.1\-2001 określa, że \fBlink\fP(2) powinno rozwiązywać \fIoldpath\fP, jeśli jest to dowiązanie symboliczne. Linux tego jednak nie robi (domyślnie Solaris zachowuje się tak samo, ale zachowanie z POSIX.1\-2001 można uzyskać odpowiednimi opcjami kompilatora). W POSIX.1\-2008 zmieniono normę, zezwalając w implementacji na oba zachowania. .SS "Polecenia nieprzechodzące przez drzewo plików" Drugim przypadkiem są dowiązania symboliczne, podawane jako argumenty nazwy pliku w wierszu polecenia poleceniom, które nie przechodzą przez drzewo plików. .P Z wyjątkami opisanymi poniżej, polecenia podążają za dowiązaniami symbolicznymi, podanymi jako argumenty w wierszu poleceń. Na przykład, jeśli istniałoby dowiązanie symboliczne \fIslink\fP wskazujące na plik o nazwie \fIafile\fP, polecenie \fIcat slink\fP wyświetliłoby zawartość pliku \fIafile\fP. .P Jest istotne, aby uświadomić sobie, że reguła ta obejmuje polecenia, które mogą opcjonalnie przechodzić przez drzewo plików np. reguła ta dotyczy polecenia \fIchown file\fP, natomiast nie dotyczy polecenia \fIchown\ \-R file\fP, ponieważ przechodzi ono przez drzewo plików (to ostatnie stanowi trzeci przypadek, opisany w podrozdziale poniżej). .P Jeśli wyraźnym zamiarem jest działanie polecenia na samym dowiązaniu symbolicznym, zamiast podążanie za nim \[em] np. jeśli chce się zmienić za pomocą \fIchown slink\fP własność pliku \fIslink\fP, niezależnie od tego, czy jest to dowiązanie symboliczne, czy też nie \[em] powinno się zastosować opcję \fI\-h\fP. W powyższym przykładzie \fIchown root slink\fP zmieniłoby własność pliku, do którego odnosi się \fIslink\fP, natomiast \fIchown\ \-h root slink\fP zmieniłoby własność samego \fIslink\fP. .P Od tej reguły istnieją pewne wyjątki: .IP \[bu] 3 Polecenia \fBmv\fP(1) i \fBrm\fP(1) nie podążają za dowiązaniami symbolicznymi podanymi jako argumenty, lecz próbują je, odpowiednio, przemianować i usunąć (proszę zauważyć, że jeśli dowiązanie symboliczne odnosi się do pliku przez ścieżkę względną, przeniesienie go do innego katalogu może równie dobrze spowodować, że przestanie ono działać, ponieważ ścieżka może nie być już poprawna). .IP \[bu] Polecenie \fBls\fP(1) również jest wyjątkiem od tej reguły. Ze względu na kompatybilność z dawnymi systemami (gdy \fBls\fP(1) nie przechodzi przez drzewo \[em] tj. nie podano opcji \fI\-R\fP), polecenie \fBls\fP(1) podąża za dowiązaniami symbolicznymi podanymi jako argumenty, jeśli podano opcje \fI\-H\fP lub \fI\-L\fP, albo gdy nie podano opcji \fI\-F\fP, \fI\-d\fP lub \fI\-l\fP (polecenie \fBls\fP(1) jest jedynym poleceniem, gdzie opcje \fI\-H\fP i \fI\-L\fP wpływają na jego zachowanie, nawet gdy nie jest dokonywane przejście przez drzewo plików). .IP \[bu] .\" .\"The 4.4BSD system differs from historical 4BSD systems in that the .\".BR chown (1) .\"and .\".BR chgrp (1) .\"commands follow symbolic links specified on the command line. Polecenie \fBfile\fP(1) również jest wyjątkiem od tej reguły. Polecenie \fBfile\fP(1) nie podąża za dowiązaniami symbolicznymi, podanymi jako argument. Polecenie \fBfile\fP(1) podąża za dowiązaniami symbolicznymi podanymi jako argument, gdy podano opcję \fI\-L\fP. .SS "Polecenia przechodzące przez drzewo plików" Polecenia, które albo opcjonalnie, albo zawsze przechodzą przez drzewo plików: \fBchgrp\fP(1), \fBchmod\fP(1), \fBchown\fP(1), \fBcp\fP(1), \fBdu\fP(1), \fBfind\fP(1), \fBls\fP(1), \fBpax\fP(1), \fBrm\fP(1) i \fBtar\fP(1). .P Jest istotne aby uświadomić sobie, że poniższe reguły stosują się zarówno do dowiązań symbolicznych napotkanych przy przechodzeniu przez drzewo plików, jak i do dowiązań symbolicznych podanych jako argumenty wiersza poleceń. .P \fIPierwsza reguła\fP stosuje się do dowiązań symbolicznych, odnoszących się do plików innych niż katalogi. Operacje, które dotyczą dowiązań symbolicznych, są wykonywane na samych dowiązaniach symbolicznych, lecz poza tym, dowiązania są ignorowane. .P Polecenie \fIrm\ \-r slink directory\fP usunie \fIslink\fP, oraz wszelkie dowiązania symboliczne napotkane przy przechodzeniu drzewa katalogu \fIdirectory\fP, ponieważ dowiązania symboliczne mogą być usuwane. W żadnym przypadku \fBrm\fP(1) nie będzie dotyczyć pliku wskazywanego przez \fIslink\fP. .P \fIDruga reguła\fP dotyczy dowiązań symbolicznych, odnoszących się do katalogów. Domyślnie, nigdy nie podąża się za dowiązaniami symbolicznymi wskazującymi na katalogi. Często nazywane jest to przejściem \[Bq]fizycznym\[rq], w odróżnieniu od przejścia \[Bq]logicznego\[rq] (gdy podąża się za dowiązaniami symbolicznymi odnoszącymi się do katalogów). .P Istnieją pewne konwencje, które są (a przynajmniej powinny być) przestrzegane, przez programy dokonujące przejścia przez drzewo plików, tak ściśle, jak to możliwe: .IP \[bu] 3 Można sprawić, aby polecenie podążało za wszelkimi dowiązaniami symbolicznymi podanymi w wierszu poleceń, niezależnie od typu pliku, do jakiego się odnoszą, podając opcję \fI\-H\fP (od ang \[Bq]half\-logical\[rq] \[em] \[Bq]półlogiczny\[rq]). Opcja ta ma na celu upodobnienie przestrzeni nazw wiersza poleceń do logicznej przestrzeni nazw (proszę zauważyć, że w przypadku poleceń, które nie zawsze przechodzą przez drzewo plików, opcja \fI\-H\fP zostanie zignorowana, jeśli nie podano również \fI\-R\fP). .IP Dla przykładu, polecenie \fIchown\ \-HR user slink\fP przejdzie przez hierarchię plików zakorzenionych w pliku, na który wskazuje \fIslink\fP. Proszę zauważyć, że \fI\-H\fP nie jest tym samym, co opisywana wcześniej opcja \fI\-h\fP. Opcja \fI\-H\fP powoduje, że dowiązania symboliczne podane w wierszu poleceń są rozwiązywane w celu zarówno przeprowadzenia akcji, jak i przejścia przez drzewo, i jest to to samo, co podanie przez użytkownika nazwy pliku, na którą wskazuje dowiązanie symboliczne. .IP \[bu] Można spowodować, aby polecenie podążało za dowiązaniami symbolicznymi podanymi w wierszu poleceń, jak również wszelkimi dowiązaniami symbolicznymi napotkanymi przy przejściu przez drzewo plików, niezależnie od typu plików, na które wskazują, podając opcję \fI\-L\fP (\[Bq]logiczny\[rq]). Opcja ta ma na celu upodobnienie całej przestrzeni nazw do logicznej przestrzeni nazw (proszę zauważyć, że w przypadku poleceń, które nie zawsze przechodzą przez drzewo plików, opcja \fI\-L\fP zostanie zignorowana, jeśli nie podano również \fI\-R\fP). .IP Dla przykładu, polecenie \fIchown\ \-LR user slink\fP zmieni właściciela pliku, do którego odnosi się \fIslink\fP. Jeśli \fIslink\fP wskazuje na katalog, \fBchown\fP przejdzie przez hierarchię plików zakorzenionych w katalogu, na który on wskazuje. Dodatkowo, wszelkie dowiązania symboliczne napotkane w dowolnym drzewie plików, przez który przejdzie \fBchown\fP, zostaną potraktowane w ten sam sposób co \fIslink\fP. .IP \[bu] Można sprawić, aby polecenie zachowało się w sposób domyślny podając opcję \fI\-P\fP (od ang. \[Bq]physical\[rq] \[em] \[Bq]fizyczny\[rq]). Opcja ta ma na celu upodobnienie całej przestrzeni nazw do fizycznej przestrzeni nazw. .P W przypadku poleceń, które domyślnie nie przechodzą przez drzewo plików, opcje \fI\-H\fP, \fI\-L\fP i \fI\-P\fP są ignorowane, jeśli nie poda się równocześnie opcji \fI\-R\fP. Dodatkowo, można podać opcje \fI\-H\fP, \fI\-L\fP i \fI\-P\fP więcej niż raz; podana jako ostatnia określa zachowanie polecenia. Ma to na celu umożliwienie utworzenia aliasów poleceń, korzystających z tych opcji, a jednocześnie umożliwienie późniejszego przesłonienie zachowania podanego w aliasie, z wiersza poleceń. .P Polecenia \fBls\fP(1) i \fBrm\fP(1) mają wyjątki do tych reguł: .IP \[bu] 3 Polecenie \fBrm\fP(1) działa na samym dowiązaniu symbolicznym, a nie na pliku, na który ono wskazuje, zatem nigdy nie podąża za dowiązaniem symbolicznym. Polecenie \fBrm\fP(1) nie obsługuje opcji \fI\-H\fP, \fI\-L\fP ani \fI\-P\fP. .IP \[bu] Aby zachować kompatybilność z dawnymi systemami, polecenie \fBls\fP(1) działa nieco odmiennie. Jeśli nie poda się opcji \fI\-F\fP, \fI\-d\fP lub \fI\-l\fP, \fBls\fP(1) będzie podążało za dowiązaniami symbolicznymi podanymi w wierszu poleceń. Jeśli poda się opcję \fI\-L\fP, \fBls\fP(1) podąża za wszelkimi dowiązaniami symbolicznymi, niezależnie od ich typu i tego, czy zostały podane w wierszu poleceń, czy napotkane przy przejściu przez drzewo. .SH "ZOBACZ TAKŻE" \fBchgrp\fP(1), \fBchmod\fP(1), \fBfind\fP(1), \fBln\fP(1), \fBls\fP(1), \fBmv\fP(1), \fBnamei\fP(1), \fBrm\fP(1), \fBlchown\fP(2), \fBlink\fP(2), \fBlstat\fP(2), \fBreadlink\fP(2), \fBrename\fP(2), \fBsymlink\fP(2), \fBunlink\fP(2), \fButimensat\fP(2), \fBlutimes\fP(3), \fBpath_resolution\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 .