unlink(2)

NAZWA
unlink, unlinkat - usuwa nazwę i może usunąć plik, do której nazwa ta się odnosi

BIBLIOTEKA
Standardowa biblioteka C (libc, -lc)

SKŁADNIA
#include <unistd.h>

int unlink(const char *pathname);

#include <fcntl.h>           /* Definicja stałych AT_* */
#include <unistd.h>

int unlinkat(int dirfd, const char *pathname, int flags);

    Wymagane ustawienia makr biblioteki glibc (patrz feature_test_macros(7)):

unlinkat():
    Od glibc 2.10:
        _POSIX_C_SOURCE >= 200809L
    Przed glibc 2.10:
        _ATFILE_SOURCE

OPIS
unlink() usuwa nazwę z systemu plików. Jeśli nazwa ta była ostatnim dowiązaniem do pliku i żaden proces nie utrzymuje tego pliku otwartego, plik jest usuwany, a przestrzeń jaką zajmował staje się dostępna do ponowego użytku.

Jeśli nazwa była ostatnim dowiązaniem do pliku, lecz istnieją procesy, które utrzymują plik otwarty, plik będzie istniał do momentu zamknięcia ostatniego, odnoszącego się do niego, deskryptora pliku.

Jeśli nazwa odnosi się do dowiązania symbolicznego, dowiązanie to jest usuwane.

Jeśli nazwa odnosiła się do gniazda, FIFO lub urządzenia, nazwa ta jest usuwana, lecz procesy, które utrzymywały obiekt otwarty, wciąż mogą go używać.

  unlinkat()
Wywołanie systemowe unlinkat() działa dokładnie w ten sam sposób jak unlink() lub rmdir(2) (w zależności od tego, czy flags zawiera AT_REMOVEDIR, czy też nie) z wyjątkiem różnic opisanych poniżej.

Jeśli ścieżka podana w pathname jest względna, to jest interpretowana w odniesieniu do katalogu, do którego odnosi się deskryptor pliku dirfd (zamiast w odniesieniu do bieżącego katalogu roboczego procesu wywołującego, jak czynią to unlink() i rmdir(2) w przypadku ścieżek względnych).

Jeśli ścieżka podana w pathname jest względna, a dirfd ma wartość specjalną AT_FDCWD, to ścieżka pathname jest interpretowana w odniesieniu do bieżącego katalogu roboczego procesu wywołującego (jak czynią to unlink() i rmdir(2)).

Jeśli ścieżka podana w pathname jest bezwzględna, to dirfd jest ignorowane.

flags jest maską bitową mogącą być określoną jako 0 lub jako suma (OR) wartości znaczników, które kontrolują działanie unlinkat(). Obecnie zdefiniowano tylko jeden taki znacznik:

AT_REMOVEDIR
    Domyślnie, unlinkat() przeprowadza odpowiednik unlink() na pathname. Jeśli podany jest znacznik AT_REMOVEDIR, to przeprowadzany jest odpowiednik rmdir(2) na pathname.

Więcej informacji o potrzebie wprowadzenia unlinkat() można znaleźć w podręczniku openat(2).

WARTOŚĆ ZWRACANA
Po pomyślnym zakończeniu zwracane jest zero. Po błędzie zwracane jest -1 i ustawiane errno, wskazując błąd.

BŁĘDY

EACCES
    Dostęp do zapisu do katalogu zawierającego pathname nie jest dozwolony dla efektywnego UID-u procesu, albo jeden z katalogów w pathname nie dozwala na uprawnienie przeszukania (zob. też path_resolution(7)).

EBUSY
    Plik pathname nie może być odlinkowany, ponieważ jest używany przez system lub inny proces np. jest punktem montowania lub oprogramowanie klienta NFS utworzyło go do reprezentacji aktywnego, ale poza tym nienazwanego i-węzła („NFS silly renamed” — „głupio przemianowane przez NFS”).

EFAULT
    pathname wskazuje poza dostępną dla użytkownika przestrzeń adresową.

EIO Wystąpił błąd wejścia/wyjścia.

EISDIR
    pathname odnosi się do katalogu (jest to wartość spoza POSIX, zwracana od Linuksa 2.1.132).

ELOOP
    Przy tłumaczeniu pathname napotkano zbyt wiele dowiązań symbolicznych.

ENAMETOOLONG
    pathname było zbyt długie.

ENOENT
    Składowa ścieżki pathname nie istnieje lub jest wiszącym dowiązaniem symbolicznych, lub pathname jest pusta.

ENOMEM
    Brak pamięci jądra.

ENOTDIR
    Składnik pathname, który powinien być katalogiem, w rzeczywistości katalogiem nie jest.

EPERM
    System nie zezwala na odlinkowanie katalogów lub odlinkowanie katalogów wymaga przywilejów, którymi nie dysponuje proces wywołujący (jest to błąd przewidziany przez POSIX, jak zaznaczono wyżej, Linux w tym przypadku zwraca EISDIR).

EPERM (tylko Linux)
    System plików nie zezwala na odlinkowanie plików.

EPERM lub EACCES
    Katalog zawierający pathname ma ustawiony bit lepkości (S_ISVTX), a efektywny UID procesu nie jest ani UID-em usuwanego pliku, ani katalogu go zawierającego oraz proces nie jest uprzywilejowany (Linux: nie ma przywileju CAP_FOWNER).

EPERM
    Plik do odlinkowania jest oznaczony jako tylko do odczytu lub tylko do nadpisu (zob. również FS_IOC_SETFLAGS(2const)).

EROFS
    pathname odnosi się do pliku w systemie plików tylko do odczytu.

Błędy, które mogą wystąpić w unlink() i rmdir(2) mogą również wystąpić w unlinkat(). Następujące dodatkowe błędy mogą wystąpić w unlinkat():

EBADF
    pathname jest względna, lecz dirfd nie wynosi ani AT_FDCWD, ani nie jest prawidłowym deskryptorem pliku.

EINVAL
    We flags podano nieprawidłową wartość znacznika.

EISDIR
    pathname odnosi się do katalogu, a we flags nie podano AT_REMOVEDIR.

ENOTDIR
    pathname jest względna a dirfd jest deskryptorem pliku odnoszącym się do pliku zamiast do katalogu.

STANDARDY
POSIX.1-2008.

HISTORIA

unlink()
    SVr4, 4.3BSD, POSIX.1-2001.

unlinkat()
    POSIX.1-2008. Linux 2.6.16, glibc 2.4.

  glibc
W starszych jądrach, gdzie unlinkat() jest niedostępne, funkcja opakowująca z glibc zapasowo korzysta z unlink() lub rmdir(2). Gdy pathname jest ścieżką względną, glibc tworzy ścieżkę w oparciu o dowiązanie symboliczne w /proc/self/fd, które odnosi się do argumentu dirfd.

USTERKI
Nietrafne rozwiązania w protokole odpowiedzialnym za obsługę NFS mogą spowodować nieoczekiwane zniknięcie plików, które są wciąż w użyciu.

ZOBACZ TAKŻE
rm(1), unlink(1), chmod(2), link(2), mknod(2), open(2), rename(2), rmdir(2), mkfifo(3), remove(3), path_resolution(7), symlink(7)

TŁUMACZENIE
Tłumaczenie niniejszej strony podręcznika: Michał Kułach <michal.kulach@gmail.com>

Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 (https://www.gnu.org/licenses/gpl-3.0.html) lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej manpages-pl-list@lists.sourceforge.net.