bug#18499: Possible mv race for hardlinks (rhbz #1141368 )

[Boris Ranto]

On Tue, 2014-11-18 at 16:46 +0000, Pádraig Brady wrote:
> On 18/11/14 16:29, Boris Ranto wrote:
> > On Mon, 2014-11-17 at 00:28 +0000, Pádraig Brady wrote:
> >> On 16/11/14 16:35, Paul Eggert wrote:
> >>> Pádraig Brady wrote:
> >>>> If we change this, it's much more likely that people will start 
> >>>> complaining
> >>>> about their non overlapping mv instances failing.
> >>>
> >>> I'd far rather deal with those complaints than deal with complaints about 
> >>> 'mv' silently discarding files.  Either the FreeBSD or the Solaris 
> >>> behavior would be a real improvement over what we're doing now.  Neither 
> >>> behavior is as good as having support in the kernel for doing the right 
> >>> thing, but one step at a time.
> >>
> >> Fair enough. That's 3 votes for changing this.
> >> I'll work on a patch to fail in this case.
> >>
> >> thanks,
> >> Pádraig.
> >>
> > 
> > I've looked at the code and I was able to identify the part that deals
> > with the symlinks. I'm attaching the patch that makes mv fail in this
> > case.
> 
> I'm not sure symlinks should be treated differently here.
> I.E. it may be best to remove the whole unlink_src logic.
> I'll look later.
> 
> thanks,
> Pádraig.

You were right, the only other place that used the unlink_src logic was
the case handling mv for symlinks that were hard links to the same file
(this case was handled separetely from the normal files) -- i.e. the
case where you do this:
touch a; ln -s a b; ln b c; mv b c

I'm attaching the revised patch that removes the whole unlink_src logic
altogether.

-Boris