[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