Scroll to navigation

UNLINK(2) Linux Programmer's Manual UNLINK(2)

名前

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():

_XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L
_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() の動作を制御するフラグ値を論理和の形で指定することができる。現在のところ、定義されているフラグはひとつだけである。

デフォルトでは、 unlinkat() は pathname に対して unlink() と等価な動作をする。 AT_REMOVEDIR フラグが指定された場合、 pathname に対して rmdir(2) と等価な動作をする。

unlinkat() の必要性についての説明については openat(2) を参照。

返り値

成功した場合は 0 が返される。エラーの場合は -1 が返され、 errno が適切に設定される。

エラー

pathname を含んでいるディレクトリの書き込み許可がプロセスの実効 (effective) ユーザー ID に与えられていないか、 pathname の中のディレクトリのどれかに検索許可が与えられていない (path_resolution(7) も参照すること)。
システムか別のプロセスがそのファイルを使用中のため、 ファイル pathname を unlink できない。 例えば、そのファイルがマウントポイントの場合や、 NFS クライアントソフトウェアがそのファイルがアクティブであるが 名前なし inode (nameless inode) であることを示すために作成した 場合 ("NFS silly renamed") などがある。
pathname がアクセス可能なアドレス空間の外を指している。
I/O エラーが発生した。
pathname がディレクトリを参照している。 (これは POSIX で規定されていない値で、Linux 2.1.132 以降で返される。)
pathname を解決する際に遭遇したシンボリックリンクが多過ぎる。
pathname が長過ぎる。
pathname に対応するものが存在しないか、壊れたシンボリックリンクであるか、 pathname が空である。
十分なカーネルメモリーがない。
pathname のディレクトリ部分が、実際には、ディレクトリでない。
システムがディレクトリに対する unlink 操作を許可していない。 またはディレクトリに対する unlink 操作のために必要な特権を 呼び出し元のプロセスが持っていない。 (これは POSIX で規定されているエラーの返し方である。 上述の通り、この場合には Linux は EISDIR を返す。)
ファイルシステムがファイルに対する unlink 操作を許していない。
pathname を含んでいるディレクトリにスティッキービット (sticky-bit) (S_ISVTX) が設定されていて、プロセスの実効ユーザー ID が削除しようとするファイルの UID でもそれを含んでいるディレクトリのものでもなく、 かつプロセスに特権がない (Linux では CAP_FOWNER ケーパビリティ (capability) がない)。
pathname が読み込み専用のファイルシステムのファイルを参照している。

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

dirfd が有効なファイルディスクリプターではない。
無効なフラグ値が flags に指定された。
pathname がディレクトリを参照していて、 flags に AT_REMOVEDIR がされていなかった。
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(2) と rmdir(2) を使用するモードにフォールバックする。 pathname が相対パスの場合、 glibc は dirfd 引き数に対応する /proc/self/fd のシンボリックリンクに基づいてパス名を構成する。

バグ

NFS プロトコルに内在する問題により、まだ使用中のファイルが想定外に消えてしまうことがありえる。

関連項目

rm(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 プロジェクトのリリース 3.79 の一部 である。プロジェクトの説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。

2014-08-19 Linux