On Mon, Dec 01, 2014 at 10:09:44PM +0530, Shriramana Sharma wrote: > On Mon, Dec 1, 2014 at 7:16 PM, Roman Mamedov <rm@xxxxxxxxxxx> wrote: > > > > A more sensible idea could be adding a global-level '-i' switch, same as in > > 'rm', so that you or distros could then alias 'btrfs' to 'btrfs -i' (ask > > confirmation on any irreversible action). > > Well the difference being that there doesn't seem to be any other > irreversible action from my scan of man btrfs -- am I missing > anything? This is the only thing that actually leads to loss of data. > > When btrfs has so many features (esp snapshots) to prevent user > accidentally deleting data (I liked especially > http://www.youtube.com/v/9H7e6BcI5Fo?start=209) I think there has to > be *some* modicum of support for warning against deleting a subvolume > (and it seems others agree too). > > But I see what you mean in the bugzilla comment about not wanting your > existing backup snapshot scripts to fail because they don't have a -f. > At the same time, aliasing via -i on top level btrfs binary may not be > so practical here because this is the only command which will actually > use it (again, correct if wrong). > > Perhaps exporting some envvar in the default shell's rc file (or > whichever file will be read only if the shell is interactive) would > work? Like in ~/.bashrc: > > 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. ;) fprintf(stderr, "Deleting subvolume '%s' in 5 seconds.\n", subvol_path); if (!f_flag_on_cmd_line) { fprintf(stderr, "If this is not what you want,\n"); fprintf(stderr, "*** PRESS Ctrl-C TO ABORT NOW!!! ***\a\n"); sleep(5); } Of course, in an init-shell-type environment, Ctrl-C doesn't work either... 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 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. 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? 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? > -- > Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा > -- > 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
Attachment:
signature.asc
Description: Digital signature
