bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6960: mv refuses to move a symlink over a hard link to the same file


From: Pádraig Brady
Subject: bug#6960: mv refuses to move a symlink over a hard link to the same file
Date: Sun, 29 Jan 2012 22:05:44 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 01/29/2012 09:33 PM, Jim Meyering wrote:

> diff --git a/src/copy.c b/src/copy.c
> index 51f51be..af79ed3 100644
> --- a/src/copy.c
> +++ b/src/copy.c
> @@ -34,6 +34,7 @@
>  #include "acl.h"
>  #include "backupfile.h"
>  #include "buffer-lcm.h"
> +#include "canonicalize.h"
>  #include "copy.h"
>  #include "cp-hash.h"
>  #include "extent-scan.h"
> @@ -1349,6 +1350,38 @@ same_file_ok (char const *src_name, struct stat const 
> *src_sb,
>          }
>      }
> 
> +  /* At this point, it is normally an error (data loss) to move a symlink
> +     onto its referent, but in at least one narrow case, it is not:
> +     In move mode, when
> +     src is a symlink,
> +     dest is not a symlink,
> +     dest has a link count of 2 or more and
> +     dest and the referent of src are not the same entry,
> +     then it's ok, since while we'll lose one of those hard links,
> +     src will still point to a remaining link.
> +
> +     Given this,
> +       $ touch f && ln f l && ln -s f s
> +       $ ls -og f l s
> +       -rw-------. 2  0 Jan  4 22:46 f
> +       -rw-------. 2  0 Jan  4 22:46 l
> +       lrwxrwxrwx. 1  1 Jan  4 22:46 s -> f
> +     this must fail: mv s f
> +     this must succeed: mv s l */
> +  if (x->move_mode
> +      && S_ISLNK (src_sb->st_mode)
> +      && ! S_ISLNK (dst_sb->st_mode)
> +      && 1 < dst_sb_link->st_nlink)
> +    {
> +      char *abs_src = canonicalize_file_name (src_name);
> +      if (abs_src)
> +        {
> +          bool result = ! same_name (abs_src, dst_name);
> +          free (abs_src);
> +          return result;
> +        }
> +    }

Well the logic follows the description at least.
I was going to say the nlink test was redundant,
but it's a bit clearer with that left, and also
it's a performance improvement in the nlink=1 case.

cheers,
Pádraig.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]