名前¶

書式¶

#include <unistd.h>

int unlink(const char *pathname);

#include <fcntl.h>           /* AT_* 定数の定義 */
#include <unistd.h>

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

glibc 向けの機能検査マクロの要件 (feature_test_macros(7) 参照):

unlinkat():

説明¶

名前がファイルへの最後のリンクであっても、どこかのプロセスが そのファイルを開いているなら、ファイルの最後のファイルディスクリプター (file descriptor) が閉じられるまでファイルは存在し続ける。

名前が指しているのがシンボリックリンクなら、そのリンクを削除する。

名前が指しているのがソケット、FIFO、デバイスの場合、名前は削除されるが、 そのソケットなどを開いているプロセスはそのまま使い続けることができる。

返り値¶

エラー¶

EACCES

pathname を含んでいるディレクトリの書き込み許可がプロセスの実効 (effective) ユーザー ID に与えられていないか、 pathname の中のディレクトリのどれかに検索許可が与えられていない (path_resolution(7) も参照すること)。

EBUSY

システムか別のプロセスがそのファイルを使用中のため、 ファイル pathname を unlink できない。 例えば、そのファイルがマウントポイントの場合や、 NFS クライアントソフトウェアがそのファイルがアクティブであるが 名前なし inode (nameless inode) であることを示すために作成した 場合 ("NFS silly renamed") などがある。

EFAULT

pathname がアクセス可能なアドレス空間の外を指している。

EIO

I/O エラーが発生した。

EISDIR

pathname がディレクトリを参照している。 (これは POSIX で規定されていない値で、Linux 2.1.132 以降で返される。)

ELOOP

pathname を解決する際に遭遇したシンボリックリンクが多過ぎる。

ENAMETOOLONG

pathname が長過ぎる。

ENOENT

pathname に対応するものが存在しないか、壊れたシンボリックリンクであるか、 pathname が空である。

ENOMEM

十分なカーネルメモリーがない。

ENOTDIR

pathname のディレクトリ部分が、実際には、ディレクトリでない。

EPERM

システムがディレクトリに対する unlink 操作を許可していない。 またはディレクトリに対する unlink 操作のために必要な特権を 呼び出し元のプロセスが持っていない。 (これは POSIX で規定されているエラーの返し方である。 上述の通り、この場合には Linux は EISDIR を返す。)

EPERM (Linux のみ)

ファイルシステムがファイルに対する unlink 操作を許していない。

EPERM または EACCES

pathname を含んでいるディレクトリにスティッキービット (sticky-bit) (S_ISVTX) が設定されていて、プロセスの実効ユーザー ID が削除しようとするファイルの UID でもそれを含んでいるディレクトリのものでもなく、 かつプロセスに特権がない (Linux では CAP_FOWNER ケーパビリティ (capability) がない)。

EROFS

pathname が読み込み専用のファイルシステムのファイルを参照している。

unlink() と rmdir(2) で発生するのと同じエラーが unlinkat() でも起こる。 unlinkat() では以下のエラーも発生する。

EBADF

dirfd が有効なファイルディスクリプターではない。

EINVAL

無効なフラグ値が flags に指定された。

EISDIR

pathname がディレクトリを参照していて、 flags に AT_REMOVEDIR がされていなかった。

ENOTDIR

pathname が相対パスで、 dirfd がディレクトリ以外のファイルを参照しているファイルディスクリプターである。

バージョン¶

準拠¶

unlinkat(): POSIX.1-2008.

注意¶

バグ¶

関連項目¶

この文書について¶