On Mon, Dec 01, 2014 at 10:14:03PM -0500, Zygo Blaxell wrote: > > export BTRFS_SUBVOLUME_DELETE_CONFIRM=1 > > > > Ideas? > > Never rely on aliasing or environment variables for defaults, and never > change default behavior if your releases are old enough that someone > has built scripts on top of them. ;) Exactly. > If I had to pick the least evil, I'd go for interactive prompting by > default (do nothing if the interaction fails, e.g. no TTY) and add a > '-f'/'--force' flag to bypass the prompt. This sounds acceptable. > This is consistent with the > way lvm2 and mdadm work when presented with data-losing or otherwise > questionable commands and parameters. It will break scripts, but btrfs > users should still be expecting that for a while as undesirable default > behaviors are identified. How is this going to break scripts? > OTOH maybe there is no issue with the current behavior. Only root can > delete subvolumes, and maybe we assume root knows what they're doing? With the mount option user_subvol_rm_allowed the user can delete subvols as well, so it makes sense to add the confirmation. > On a side note...only root can delete subvolumes, but non-root users > can create them, which results in...this: > > $ /sbin/btrfs sub create foo > Create subvolume './foo' > $ date > foo/bar > $ /sbin/btrfs sub delete foo > Transaction commit: none (default) > Delete subvolume '/home/testuser/foo' > ERROR: cannot delete '/home/testuser/foo' - Operation not permitted > $ rm -rf foo > rm: cannot remove `foo': Operation not permitted > $ cat /proc/version > Linux version 3.17.1-zb64+ (root@buildbot) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP PREEMPT Tue Oct 21 00:17:49 EDT 2014 > > ...uh oh? That's how it works now. I'd like to enable the user to delete their subvolumes even without the user_subvol_rm_allowed option someday. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
