On Wed, October 09, 2013 at 18:26 (+0200), Josef Bacik wrote: > btrfs_rename was using the root of the old dir instead of the root of the new > dir when checking for a hash collision, so if you tried to move a file into a > subvol it would freak out because it would see the file you are trying to move > in its current root. This fixes the bug where this would fail > > btrfs subvol create test1 > btrfs subvol create test2 > mv test1 test2. > > Thanks to Chris Murphy for catching this, > > Reported-by: Chris Murphy <li...@colorremedies.com> > Signed-off-by: Josef Bacik <jba...@fusionio.com> > --- > fs/btrfs/inode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > index 1d7ef37..d468246 100644 > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -7993,7 +7993,7 @@ static int btrfs_rename(struct inode *old_dir, struct > dentry *old_dentry, > > > /* check for collisions, even if the name isn't there */ > - ret = btrfs_check_dir_item_collision(root, new_dir->i_ino, > + ret = btrfs_check_dir_item_collision(dest, new_dir->i_ino, > new_dentry->d_name.name, > new_dentry->d_name.len);
Looks correct. I claim that better variable names would have had avoided this bug. The code uses old_dir / new_dir, old_entry / new_entry, old_inode / new_inode - so, while you're at it: How about changing the variables to old_root / new_root instead of keeping root / dest? - Jan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
