Btrfs devel - Aug 2013 - [PATCH] Btrfs: don't allow a subvol to be deleted if it is the default subovl

Eric pointed out that btrfs will happily allow you to delete the default subvol.
This is a problem obviously since the next time you go to mount the file system
it will freak out because it can''t find the root.  Fix this by adding a
check to
see if our default subvol points to the subvol we are trying to delete, and if
it does not allowing it to happen.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
---
 fs/btrfs/ioctl.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 2312c0f..107c5f4 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1726,13 +1726,28 @@ out:
 static noinline int may_destroy_subvol(struct btrfs_root *root)
 {
 	struct btrfs_path *path;
+	struct btrfs_dir_item *di;
 	struct btrfs_key key;
+	u64 dir_id;
 	int ret;
 
 	path = btrfs_alloc_path();
 	if (!path)
 		return -ENOMEM;
 
+	/* Make sure this root isn''t set as the default subvol */
+	dir_id = btrfs_super_root_dir(root->fs_info->super_copy);
+	di = btrfs_lookup_dir_item(NULL, root->fs_info->tree_root, path,
+				   dir_id, "default", 7, 0);
+	if (di && !IS_ERR(di)) {
+		btrfs_dir_item_key_to_cpu(path->nodes[0], di, &key);
+		if (key.objectid == root->root_key.objectid) {
+			ret = -ENOTEMPTY;
+			goto out;
+		}
+		btrfs_release_path(path);
+	}
+
 	key.objectid = root->root_key.objectid;
 	key.type = BTRFS_ROOT_REF_KEY;
 	key.offset = (u64)-1;
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Josef Bacik posted on Mon, 12 Aug 2013 15:39:35 -0400 as excerpted:
> Fix this by adding a check to see if our default subvol points to the
> subvol we are trying to delete, and if it does not allowing it to
> happen.
Umm... not to be a grammar policeman, but...

That last sub-sentence REALLY (!!) needs another comma:

... and if it does, not allowing it to happen.

or

... and if it does not, allowing it to happen.

The way it is now ends up triggering for the reader a serious logical 
train wreck, as "does not" and "not allowing" both
"want" to be parsed
together, but "does not allowing" derails the whole thing and the
reader
must start over, taking it more slowly this time, trying to figure out 
where the parsing derailed the first time through and what was actually 
intended!

(FWIW, being a languagelog.net feed subscriber and regular reader, I see 
instances of this sort of logical train wreck, as it''s frequently 
analogized, feature there regularly.  Linguists know it as an interesting 
quirk of the English language both created and spotted regularly by 
experts and novices alike, sometimes with rather amusing consequences!)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Aug 13, 2013 at 04:54:32AM +0000, Duncan wrote:
> Josef Bacik posted on Mon, 12 Aug 2013 15:39:35 -0400 as excerpted:
> 
> > Fix this by adding a check to see if our default subvol points to the
> > subvol we are trying to delete, and if it does not allowing it to
> > happen.
> 
> Umm... not to be a grammar policeman, but...
> 
> That last sub-sentence REALLY (!!) needs another comma:
> 
> ... and if it does, not allowing it to happen.
> 
> or
> 
> ... and if it does not, allowing it to happen.
>
I''ll fix it up in git, sorry English isn''t my first language. 
Thanks,

Josef 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html