Provided by: manpages-ja-dev_0.5.0.0.20221215+dfsg-1_all 
名前
unlink, unlinkat - 名前を削除し、場合によってはそれが参照しているファイルも削除する
書式
#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():
glibc 2.10 以降:
_POSIX_C_SOURCE >= 200809L
glibc 2.10 より前:
_ATFILE_SOURCE
説明
unlink() はファイルシステム上の名前を削除する。 もしその名前がファイルへの最後のリンク
(link) であり、 どのプロセスもそのファイルをオープン (open) していなければ、 ファイルは削
除される。 ファイルが使用していたディスク上の領域は再利用が可能になる。
名前がファイルへの最後のリンクであっても、どこかのプロセスが そのファイルを開いているな
ら、ファイルの最後のファイルディスクリプター (file descriptor) が閉じられるまでファイルは
存在し続ける。
名前が指しているのがシンボリックリンクなら、そのリンクを削除する。
名前が指しているのがソケット、FIFO、デバイスの場合、名前は削除されるが、 そのソケットなど
を開いているプロセスはそのまま使い続けることができる。
unlinkat()
unlinkat() システムコールは、unlink() と rmdir(2) のいずれかと全く同じ動作をする (どちらと
同じになるかは flags に AT_REMOVEDIR フラグが指定されたかにより決まる) が、以下で説明する
点が異なる。
pathname で指定されたパス名が相対パスの場合、このパス名はファイルディスクリプター dirfd が
参照するディレクトリに対する相対パスと解釈される (unlink() や rmdir(2) に相対パス名を渡し
た場合のように、呼び出したプロセスのカレントワーキングディレクトリに対する相対パスではな
い)。
pathname で指定されたパス名が相対パスで、 dirfd が特別な値 AT_FDCWD の場合、 (unlink() や
rmdir(2) と同様に) pathname は呼び出したプロセスのカレントワーキングディレクトリに対する相
対パスと解釈される。
pathname で指定されたパス名が絶対パスの場合、 dirfd は無視される。
flags はビットマスクで、0 もしくは unlinkat() の動作を制御するフラグ値を論理和の形で指定す
ることができる。現在のところ、定義されているフラグはひとつだけである。
AT_REMOVEDIR
デフォルトでは、 unlinkat() は pathname に対して unlink() と等価な動作をする。
AT_REMOVEDIR フラグが指定された場合、 pathname に対して rmdir(2) と等価な動作をす
る。
unlinkat() の必要性についての説明については openat(2) を参照。
返り値
成功した場合は 0 が返される。エラーの場合は -1 が返され、 errno が適切に設定される。
エラー
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) がない)。
EPERM The file to be unlinked is marked immutable or append-only. (See ioctl_iflags(2).)
EROFS pathname が読み込み専用のファイルシステムのファイルを参照している。
unlink() と rmdir(2) で発生するのと同じエラーが unlinkat() でも起こる。 unlinkat() では以
下のエラーも発生する。
EBADF dirfd が有効なファイルディスクリプターではない。
EINVAL 無効なフラグ値が flags に指定された。
EISDIR pathname がディレクトリを参照していて、 flags に AT_REMOVEDIR がされていなかった。
ENOTDIR
pathname が相対パスで、 dirfd がディレクトリ以外のファイルを参照しているファイル
ディスクリプターである。
バージョン
unlinkat() はカーネル 2.6.16 で Linux に追加された。 ライブラリによるサポートはバージョン
2.4 で glibc に追加された。
準拠
unlink(): SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
unlinkat(): POSIX.1-2008.
注意
glibc での注意
unlinkat() が利用できない古いカーネルでは、 glibc ラッパー関数は unlink() と rmdir(2) を使
用するモードにフォールバックする。 pathname が相対パスの場合、 glibc は dirfd 引数に対応す
る /proc/self/fd のシンボリックリンクに基づいてパス名を構成する。
バグ
NFS プロトコルに内在する問題により、まだ使用中のファイルが想定外に消えてしまうことがありえ
る。
関連項目
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)
この文書について
この man ページは Linux man-pages プロジェクトのリリース 5.10 の一部である。プロジェクトの
説明とバグ報告に関する情報は https://www.kernel.org/doc/man-pages/ に書かれている。