Re: Scrub resume regression

[Graham Cobb <g.btrfs@cobb.uk.net>]

On 17/01/2020 18:39, Chris Murphy wrote:
> It's no one's fault, it's just confusing. :P
> 
> Cancel word origin means more than stop, implies resetting state, to
> obliterate or invalidate.
> 
> Pause and stop word origin suggests they're interchangeable, but in
> practice with digital audio and video consumer gear, stop has come to
> mean a kind of cancel. (I'm gonna ignore tape.) Where a start from a
> stop will start at the very beginning. Whereas pause saves state and
> unpause means resume.
> 
> Lightweight change, add new command stop, which saves state, and
> cancel is an alias for backward compatibility. No other change.

That seems fairly pointless.

> Moderate change:
> start = alias resume

start and resume do different things today. The distinction is important
as the "saved state" after a cancel stays around until the next scrub
starts (it could be months old).

> stop = alias cancel
> i.e. a stop then start does the same thing as a cancel then resume,
> unless new command 'reset' is used
> reset = stops, and resets state to the beginning

That really isn't useful. It is much more useful to be able to decide
whether to use the saved state at start time than it is to decide
whether to save state at stop time. To build on Zygo's example, I might
have a script which pauses the scrub when the system load goes up and
then decides whether to resume it or restart from scratch depending on
how long it has been paused for. Also, the saved state can be inspected
while the scrub is paused to allow the operator to estimate how long it
might take to complete.

> Heavier change that's linguistically sane, but breaks expectations of
> today's cancel:
> pause and unpause (alias resume), and start and stop (alias cancel).
> The former is stateful, and the latter is stateless.

Changing the meaning of the current start, resume, or cancel commands
isn't an option - these are built into user scripts.