kazmax - Linux で自宅サーバー

rename - システムコールの説明 - Linux コマンド集 一覧表

  1. 名前
  2. 書式
  3. 説明
  4. 返り値
  5. エラー
  6. 準拠
  7. バグ
  8. 関連項目

名前

rename - ファイルの名前や位置を変更する

書式

#include <stdio.h>
int rename(const char * oldpath , const char * newpath );

説明

rename ()はファイルの名前を変え、必要ならばディレクトリ間の移動を行なう。
そのファイルに対する他の ( link (2)を使用して作られた) ハード・リンク (hard link) には影響はない。
newpath が既に存在する場合、それは不可分操作で (atomically) 置き換えられる (ただし、いくつかの条件がある; 以下の「エラー」のセクションを参照せよ)。 そのため、 newpath にアクセスしようとしている他のプロセスがファイルを見失うことはない (訳註: 常にアクセス可能である)。
newpath が存在し、何らかの理由で操作が失敗した場合、 rename ()は newpath の実体を元のまま残すことを保証する。
一方で、上書きを行なう場合は、rename が行なわれるファイルを oldpathnewpath の両方で参照できる瞬間がおそらく存在する。
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
newpatholdpath のパス部分を含んでいる。より一般に ディレクトリを自分自身のサブディレクトリに変更しようとした。
EISDIR
newpath は存在しているディレクトリであるが、 oldpath はディレクトリでない。
ELOOP
oldpath または newpath を解決する際に遭遇したシンボリック・リンクが多過ぎる。
EMLINK
oldpath は既に最大数までのリンクを持っているか、それがディレクトリで newpath を含んでいるディレクトリが最大数までのリンクを持っている。
ENAMETOOLONG
oldpath または newpath が長過ぎる。
ENOENT
oldpath または newpath のディレクトリ部分が存在しないか、 壊れた (dangling) シンボリック・リンクである。
ENOMEM
カーネル (kernel) に十分なメモリ (memory) が存在しない。
ENOSPC
ファイルを含んでいるデバイスに新しいディレクトリ・エントリを 作成するための空きがない。
ENOTDIR
oldpathnewpath に含まれているディレクトリ部分が 実際にはディレクトリでない。 または 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 ケーパビリティがない)。 または oldpathnewpath を含んでいるファイル・システムが、要求したような型の名前の変更を サポートしていない。
EROFS
ファイルが読み込み専用 (read-only) ファイル・システムにある。
EXDEV
oldpathnewpath が同じマウントされたファイル・システムに存在しない。 (Linux は 1 つのファイル・システムを複数のマウント位置に マウントすることを許可している。 しかし   rename (2) は、たとえ同じファイル・システムであっても、 別々のマウント位置を跨いでは動作しない。)

準拠

4.3BSD, C89, POSIX.1-2001.

バグ

NFS ファイル・システムでは、操作が失敗したからといって、 ファイルの名前が変更できなかったと決めてかかることはできない。 サーバ (server) が rename 操作を終えてからクラッシュした場合、 サーバが再び立ち上がったときに、 再送信された RPC が処理されるが、これは失敗となる。 アプリケーションはこの問題を正しく取り扱うことが期待される。 同様の問題に関して   link (2) を参照せよ。

関連項目