From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexander Viro <viro@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
In-Reply-To: <87r8sebqt8.fsf@becket.becket.net>
Message-ID: <Pine.GSO.4.21.0110080610370.11810-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Date: Mon,  8 Oct 2001 06:30:25 -0400
Topicbox-Message-UUID: 01c781ce-eaca-11e9-9e20-41e7f4b1d025



On Mon, 8 Oct 2001, Thomas Bushnell, BSG wrote:

> viro@math.psu.edu (Alexander Viro) writes:
> 
> > So can anybody who had seen current 4.4BSD derivatives.  _None_ of them
> > got it right.  rename()/rename() race (creating a loop and detaching it
> > from the rest of tree) is still there.
> 
> I'm pretty sure you're incorrect.  Can you describe the case in more
> detail? 

I'm pretty sure in the opposite and unfortunately *BSD source happens to
agree with me.  Consider the scenario I've described upthread (s/ELOOP/EINVAL/
- sorry about the braino) and think what happens if both renames get to
ufs_checkpath() simultaneously.  See /src/ufs/ufs/ufs_vnode.c::ufs_rename()
for details.  Notice that none of the lookups is going to come anywhere near
the vnodes affected by another rename() and ufs_checkpath() is called with
fvp unlocked and it unlocks dp (parent of fvp).