From: Edward Shishkin <edward.shishkin@gmail.com>
To: Ivan Shapovalov <intelfx100@gmail.com>, reiserfs-devel@vger.kernel.org
Subject: Re: [PATCH] reiser4: implement ->rename2() of struct inode_operations.
Date: Fri, 27 Feb 2015 12:57:41 +0100 [thread overview]
Message-ID: <54F05BB5.5030104@gmail.com> (raw)
In-Reply-To: <1424992884-29692-1-git-send-email-intelfx100@gmail.com>
On 02/27/2015 12:21 AM, Ivan Shapovalov wrote:
> For now, only support the basic case of flags == 0.
> Also support the case of flags == RENAME_NOREPLACE, because it is a no-op for
> local filesystems (destination existence is already checked by VFS).
Great,
Thanks!
> Thus no functional changes to the existing code.
>
> Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
> ---
>
> Could you please estimate whether it would be hard to also implement the
> RENAME_EXCHANGE flag?
Why do we need this?
Thanks,
Edward.
> It is defined as follows:
>
> Atomically exchange oldpath and newpath. Both pathnames must exist but may
> be of different types (e.g., one could be a non-empty directory and the other
> a symbolic link).
>
> If there are no caveats, I'll try to do it as a kind of a junior job...
>
> fs/reiser4/plugin/inode_ops_rename.c | 47 ++++++++++++++++++++++++++++++------
> fs/reiser4/plugin/object.c | 2 +-
> fs/reiser4/plugin/object.h | 5 ++--
> 3 files changed, 44 insertions(+), 10 deletions(-)
>
> diff --git a/fs/reiser4/plugin/inode_ops_rename.c b/fs/reiser4/plugin/inode_ops_rename.c
> index 4d461dc..6744e14 100644
> --- a/fs/reiser4/plugin/inode_ops_rename.c
> +++ b/fs/reiser4/plugin/inode_ops_rename.c
> @@ -288,7 +288,7 @@ int reiser4_find_entry(struct inode *, struct dentry *, lock_handle * ,
> znode_lock_mode, reiser4_dir_entry_desc *);
> int reiser4_update_dir(struct inode *);
>
> -/* this is common implementation of vfs's rename method of struct
> +/* this is common implementation of vfs's rename2 method of struct
> inode_operations
> See comments in the body.
>
> @@ -299,12 +299,13 @@ int reiser4_update_dir(struct inode *);
> entry. This should be re-considered when more than one different
> directory plugin will be implemented.
> */
> -int reiser4_rename_common(struct inode *old_dir /* directory where @old
> - * is located */ ,
> - struct dentry *old_name /* old name */ ,
> - struct inode *new_dir /* directory where @new
> - * is located */ ,
> - struct dentry *new_name/* new name */)
> +int reiser4_rename2_common(struct inode *old_dir /* directory where @old
> + * is located */ ,
> + struct dentry *old_name /* old name */ ,
> + struct inode *new_dir /* directory where @new
> + * is located */ ,
> + struct dentry *new_name /* new name */ ,
> + unsigned flags /* specific flags */)
> {
> /* From `The Open Group Base Specifications Issue 6'
>
> @@ -384,6 +385,26 @@ int reiser4_rename_common(struct inode *old_dir /* directory where @old
> [N/A]
>
> */
> +
> + /* From Documentation/filesystems/vfs.txt:
> +
> + rename2: this has an additional flags argument compared to rename.
> + f no flags are supported by the filesystem then this method
> + need not be implemented. If some flags are supported then the
> + filesystem must return -EINVAL for any unsupported or unknown
> + flags. Currently the following flags are implemented:
> + (1) RENAME_NOREPLACE: this flag indicates that if the target
> + of the rename exists the rename should fail with -EEXIST
> + instead of replacing the target. The VFS already checks for
> + existence, so for local filesystems the RENAME_NOREPLACE
> + implementation is equivalent to plain rename.
> + (2) RENAME_EXCHANGE: exchange source and target. Both must
> + exist; this is checked by the VFS. Unlike plain rename,
> + source and target may be of different type.
> + */
> +
> + static const unsigned supported_flags = RENAME_NOREPLACE;
> +
> reiser4_context *ctx;
> int result;
> int is_dir; /* is @old_name directory */
> @@ -405,6 +426,18 @@ int reiser4_rename_common(struct inode *old_dir /* directory where @old
> if (IS_ERR(ctx))
> return PTR_ERR(ctx);
>
> + /*
> + * Check rename2() flags.
> + *
> + * "If some flags are supported then the filesystem must return
> + * -EINVAL for any unsupported or unknown flags."
> + *
> + * We support:
> + * - RENAME_NOREPLACE (no-op)
> + */
> + if (flags & supported_flags != flags)
> + return RETERR(-EINVAL);
> +
> old_entry = kzalloc(3 * sizeof(*old_entry) + 2 * sizeof(*new_lh) +
> sizeof(*dotdot_name) + sizeof(*dataonstack),
> reiser4_ctx_gfp_mask_get());
> diff --git a/fs/reiser4/plugin/object.c b/fs/reiser4/plugin/object.c
> index 553f1e2..1b86408 100644
> --- a/fs/reiser4/plugin/object.c
> +++ b/fs/reiser4/plugin/object.c
> @@ -241,7 +241,7 @@ static struct inode_operations directory_i_ops = {
> .mkdir = reiser4_mkdir_common,
> .rmdir = reiser4_unlink_common,
> .mknod = reiser4_mknod_common,
> - .rename = reiser4_rename_common,
> + .rename2 = reiser4_rename2_common,
> .permission = reiser4_permission_common,
> .setattr = reiser4_setattr_common,
> .getattr = reiser4_getattr_common
> diff --git a/fs/reiser4/plugin/object.h b/fs/reiser4/plugin/object.h
> index 80aef3e..f8a5133 100644
> --- a/fs/reiser4/plugin/object.h
> +++ b/fs/reiser4/plugin/object.h
> @@ -22,8 +22,9 @@ int reiser4_symlink_common(struct inode *parent, struct dentry *dentry,
> const char *linkname);
> int reiser4_mknod_common(struct inode *parent, struct dentry *dentry,
> umode_t mode, dev_t rdev);
> -int reiser4_rename_common(struct inode *old_dir, struct dentry *old_name,
> - struct inode *new_dir, struct dentry *new_name);
> +int reiser4_rename2_common(struct inode *old_dir, struct dentry *old_name,
> + struct inode *new_dir, struct dentry *new_name,
> + unsigned flags);
> void *reiser4_follow_link_common(struct dentry *, struct nameidata *data);
> int reiser4_permission_common(struct inode *, int mask);
> int reiser4_setattr_common(struct dentry *, struct iattr *);
next prev parent reply other threads:[~2015-02-27 11:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 23:21 [PATCH] reiser4: implement ->rename2() of struct inode_operations Ivan Shapovalov
2015-02-27 11:57 ` Edward Shishkin [this message]
2015-02-27 17:42 ` Ivan Shapovalov
-- strict thread matches above, loose matches on Subject: below --
2016-09-30 6:49 Ivan Shapovalov
2016-10-04 15:40 ` Edward Shishkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F05BB5.5030104@gmail.com \
--to=edward.shishkin@gmail.com \
--cc=intelfx100@gmail.com \
--cc=reiserfs-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.