rename - システムコールの説明 - Linux コマンド集 一覧表
名前
rename - ファイルの名前や位置を変更する
書式
#include <stdio.h>
int rename(const char *
oldpath
, const char *
newpath
);
説明
rename
()はファイルの名前を変え、必要ならばディレクトリ間の移動を行なう。
そのファイルに対する他の
(
link
(2)を使用して作られた) ハード・リンク (hard link) には影響はない。
newpath
が既に存在する場合、それは不可分操作で (atomically) 置き換えられる
(ただし、いくつかの条件がある; 以下の「エラー」のセクションを参照せよ)。
そのため、
newpath
にアクセスしようとしている他のプロセスがファイルを見失うことはない
(訳註: 常にアクセス可能である)。
newpath
が存在し、何らかの理由で操作が失敗した場合、
rename
()は
newpath
の実体を元のまま残すことを保証する。
一方で、上書きを行なう場合は、rename が行なわれるファイルを
oldpath
と
newpath
の両方で参照できる瞬間がおそらく存在する。
oldpath
がシンボリック・リンク (symbolic link) を参照している場合は、
リンクの名前が変更される。
また、
newpath
がシンボリック・リンクを参照している場合は、リンクが上書きされる。
返り値
成功した場合は 0 を返す。エラーの場合は -1 を返し、 errno を適切に設定する。
エラー
- EACCES
- oldpath または newpath を含んでいるディレクトリの書き込み許可がないか、 oldpath または newpath のディレクトリ部分のどれかに検索許可がないか、 oldpath がディレクトリで ( .. エントリーを更新するのに必要な) 書き込み許可がない ( path_resolution (2)も参照すること)。
- EBUSY
- oldpath または newpath がディレクトリでプロセスによって使用されている (多分、カレント・ワーキング・ディレクトリか、ルートディレクトリか、 読み込みのためにオープンされている) か、システムによって使用されている (例えばマウント・ポイントである) かの状態でシステムがこれをエラーである と判断したために rename が失敗した。 (このような場合に EBUSY を返すことは規格では要求されていない点に 注意すること。このような場合に、rename をとにかく実行してみるのは 何の問題もない。ただし、システムがそのような状況を他に扱えない 場合には EBUSY を返すことが許されている。)
- EFAULT
- oldpath または newpath がアクセス可能なアドレス空間の外を指している。
- EINVAL
- newpath が oldpath のパス部分を含んでいる。より一般に ディレクトリを自分自身のサブディレクトリに変更しようとした。
- EISDIR
- newpath は存在しているディレクトリであるが、 oldpath はディレクトリでない。
- ELOOP
- oldpath または newpath を解決する際に遭遇したシンボリック・リンクが多過ぎる。
- EMLINK
- oldpath は既に最大数までのリンクを持っているか、それがディレクトリで newpath を含んでいるディレクトリが最大数までのリンクを持っている。
- ENAMETOOLONG
- oldpath または newpath が長過ぎる。
- ENOENT
- oldpath または newpath のディレクトリ部分が存在しないか、 壊れた (dangling) シンボリック・リンクである。
- ENOMEM
- カーネル (kernel) に十分なメモリ (memory) が存在しない。
- ENOSPC
- ファイルを含んでいるデバイスに新しいディレクトリ・エントリを 作成するための空きがない。
- ENOTDIR
- oldpath か newpath に含まれているディレクトリ部分が 実際にはディレクトリでない。 または oldpath がディレクトリで、 newpath が存在してディレクトリでない。
- ENOTEMPTY " または " EEXIST
- newpath が空でないディレクトリである。すなわち "." と ".." 以外を含んでいる。
- EPERM または EACCES
- oldpath のあるディレクトリにスティッキー・ビット (sticky bit) ( S_ISVTX )が設定されており、 プロセスの実効ユーザー ID が 削除しようとするファイルのユーザー ID とも それを含んでいるディレクトリのユーザー ID とも一致せず、 プロセスに特権がない (Linux では CAP_FOWNER ケーパビリティ (capability) がない)。 または newpath が存在するファイルで親ディレクトリにスティッキービットが設定されており、 プロセスの実効ユーザー ID が 置き換えようとするファイルのユーザー ID とも それを含んでいるディレクトリのユーザー ID とも一致せず、 プロセスに特権がない (Linux では CAP_FOWNER ケーパビリティがない)。 または oldpath と newpath を含んでいるファイル・システムが、要求したような型の名前の変更を サポートしていない。
- EROFS
- ファイルが読み込み専用 (read-only) ファイル・システムにある。
- EXDEV
- oldpath と newpath が同じマウントされたファイル・システムに存在しない。 (Linux は 1 つのファイル・システムを複数のマウント位置に マウントすることを許可している。 しかし rename (2) は、たとえ同じファイル・システムであっても、 別々のマウント位置を跨いでは動作しない。)
準拠
4.3BSD, C89, POSIX.1-2001.
バグ
NFS ファイル・システムでは、操作が失敗したからといって、 ファイルの名前が変更できなかったと決めてかかることはできない。 サーバ (server) が rename 操作を終えてからクラッシュした場合、 サーバが再び立ち上がったときに、 再送信された RPC が処理されるが、これは失敗となる。 アプリケーションはこの問題を正しく取り扱うことが期待される。 同様の問題に関して link (2) を参照せよ。
関連項目
mv
(1),
chmod
(2),
link
(2),
path_resolution
(2),
renameat
(2),
symlink
(2),
unlink
(2)