On Wed, Dec 03, 2014 at 07:26:33PM +0100, David Sterba wrote: > On Tue, Dec 02, 2014 at 02:09:45PM +0000, Hugo Mills wrote: > > On Tue, Dec 02, 2014 at 01:52:52PM +0100, David Sterba wrote: > > > 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? > > > > Any script which relies on being able to delete subvolumes in > > unattended operation will now require modification to use -f. > > Even with the tty/interactive shell detection in place? Maybe I > understood the reference to lvm/mdadm tools wrong. My idea is that the > scripts would work as now, no prompts there.
How do we reliably distinguish between "running in a script interactively", "running in a script non-interactively", and "running interactively"? I could easily run a script from the command line that creates and destroys subvols and runs for days or weeks (in fact, I quite often do). It would be a significant productivity hit if an upgrade made it stop every night waiting for confirmation from a user who went home hours ago and won't be back for hours more.
signature.asc
Description: Digital signature
