OSDN Git Service

vfs: add RENAME_NOREPLACE flag
authorMiklos Szeredi <mszeredi@suse.cz>
Tue, 1 Apr 2014 15:08:43 +0000 (17:08 +0200)
committerMiklos Szeredi <mszeredi@suse.cz>
Tue, 1 Apr 2014 15:08:43 +0000 (17:08 +0200)
commit0a7c3937a1f23f8cb5fc77ae01661e9968a51d0c
tree8924086bfd279409f9eb83aab9a6177e0748b257
parent520c8b16505236fc82daa352e6c5e73cd9870cff
vfs: add RENAME_NOREPLACE flag

If this flag is specified and the target of the rename exists then the
rename syscall fails with EEXIST.

The VFS does the existence checking, so it is trivial to enable for most
local filesystems.  This patch only enables it in ext4.

For network filesystems the VFS check is not enough as there may be a race
between a remote create and the rename, so these filesystems need to handle
this flag in their ->rename() implementations to ensure atomicity.

Andy writes about why this is useful:

"The trivial answer: to eliminate the race condition from 'mv -i'.

Another answer: there's a common pattern to atomically create a file
with contents: open a temporary file, write to it, optionally fsync
it, close it, then link(2) it to the final name, then unlink the
temporary file.

The reason to use link(2) is because it won't silently clobber the destination.

This is annoying:
 - It requires an extra system call that shouldn't be necessary.
 - It doesn't work on (IMO sensible) filesystems that don't support
hard links (e.g. vfat).
 - It's not atomic -- there's an intermediate state where both files exist.
 - It's ugly.

The new rename flag will make this totally sensible.

To be fair, on new enough kernels, you can also use O_TMPFILE and
linkat to achieve the same thing even more cleanly."

Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reviewed-by: J. Bruce Fields <bfields@redhat.com>
fs/ext4/namei.c
fs/namei.c
include/uapi/linux/fs.h