On 21.06.19 22:58, John Snow wrote: > > > On 6/21/19 9:44 AM, Vladimir Sementsov-Ogievskiy wrote:
[...] Just chiming in on this: >> "So on cancel and abort you synchronize bitmap too?" > > I will concede that this means that if you ask for a bitmap backup with > the 'always' policy and, for whatever reason change your mind about > this, there's no way to "cancel" the job in a manner that does not edit > the bitmap at this point. > > I do agree that this seems to go against the wishes of the user, because > we have different "kinds" of cancellations: > > A) Cancellations that actually represent failures in transactions > B) Cancellations that represent genuine user intention > > It might be nice to allow the user to say "No wait, please don't edit > that bitmap, I made a mistake!" So that “always” doesn’t mean “always”? To me, that seems like not so good an idea. If the user uses always, they have to live with that. I had to live with calling “rm” on the wrong file before. Life’s tough. In all seriousness: “Always” is not something a user would use, is it? It’s something for management tools. Why would they cancel because “They made a mistake”? Second, what’s the worst thing that may come out of such a mistake? Having to perform a full backup? If so, that doesn’t seem so bad to me. It certainly doesn’t seem so bad to make an unrelated mechanic have an influence on whether “always” means “always”. Also, this cancel idea would only work for jobs where the bitmap mode does not come into play until the job is done, i.e. backup. I suppose if we want to have bitmap modes other than 'always' for mirror, that too would have to make a copy of the user-supplied bitmap, so there the bitmap mode would make a difference only at the end of the job, too, but who knows. And if it only makes a difference at the end of the job, you might as well just add a way to change a running job’s bitmap-mode. Max
signature.asc
Description: OpenPGP digital signature
