[linux-cifs-client] Re: [PATCH] cifs: fix renaming one hardlink on
top of another
Steve French
smfrench at gmail.com
Mon Nov 3 15:12:53 GMT 2008
This fix looks right ... unfortunately the old code (2.6.27 and
earlier) had a similar bug, it looks like it returned EEXIST for this
case.
What are you using to test this - the mv command does not obey posix
semantics (does not call rename in vfs) and I am not convinced that
the rename command does either.
On Mon, Nov 3, 2008 at 8:07 AM, Jeff Layton <jlayton at redhat.com> wrote:
> POSIX says that renaming one hardlink on top of another to the same
> inode is a no-op. We had the logic mostly right, but forgot to clear
> the return code.
>
> Signed-off-by: Jeff Layton <jlayton at redhat.com>
> ---
> fs/cifs/inode.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
> index d54fa8a..ff8c68d 100644
> --- a/fs/cifs/inode.c
> +++ b/fs/cifs/inode.c
> @@ -1361,9 +1361,11 @@ int cifs_rename(struct inode *source_dir, struct dentry *source_dentry,
> CIFS_MOUNT_MAP_SPECIAL_CHR);
>
> if (tmprc == 0 && (info_buf_source->UniqueId ==
> - info_buf_target->UniqueId))
> + info_buf_target->UniqueId)) {
> /* same file, POSIX says that this is a noop */
> + rc = 0;
> goto cifs_rename_exit;
> + }
> } /* else ... BB we could add the same check for Windows by
> checking the UniqueId via FILE_INTERNAL_INFO */
>
> --
> 1.5.5.1
>
>
--
Thanks,
Steve
More information about the linux-cifs-client
mailing list