| 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():
unlink() はファイルシステム上の名前を削除する。 もしその名前がファイルへの最後のリンク (link) であり、 どのプロセスもそのファイルをオープン (open) していなければ、 ファイルは削除される。 ファイルが使用していたディスク上の領域は再利用が可能になる。
名前がファイルへの最後のリンクであっても、どこかのプロセスが そのファイルを開いているなら、ファイルの最後のファイルディスクリプター (file descriptor) が閉じられるまでファイルは存在し続ける。
名前が指しているのがシンボリックリンクなら、そのリンクを削除する。
名前が指しているのがソケット、FIFO、デバイスの場合、名前は削除されるが、 そのソケットなどを開いているプロセスはそのまま使い続けることができる。
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() の必要性についての説明については openat(2) を参照。
成功した場合は 0 が返される。エラーの場合は -1 が返され、 errno が適切に設定される。
unlink() と rmdir(2) で発生するのと同じエラーが unlinkat() でも起こる。 unlinkat() では以下のエラーも発生する。
unlinkat() はカーネル 2.6.16 で Linux に追加された。 ライブラリによるサポートはバージョン 2.4 で glibc に追加された。
unlink(): SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
unlinkat(): POSIX.1-2008.
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 |