#2253 Issue closed: Do not abort 'rear recover' in case of invalid user input - let the user retry if possible

Labels: enhancement, cleanup, fixed / solved / done

jsmeix opened issue at 2019-10-16 11:21:

While working on https://github.com/rear/rear/pull/2252
there in particular while I did a "by the way" overhaul of
usr/share/rear/verify/TSM/default/390_request_point_in_time_restore_parameters.sh
and
usr/share/rear/verify/NBU/default/390_request_point_in_time_restore_parameters.sh
I noticed that both scripts abort 'rear recover'
when the user did an invalid date or time input.

I think this is too hard and unfriendly in this particular case.

I think if possible there should be an endless retry loop
until the user provided valid input (or intentionally aborts).

As an example how the user could retry things in case of failures see
https://github.com/rear/rear/blob/master/usr/share/rear/layout/recreate/default/200_run_layout_code.sh
how the user can run the disk layout recreation code (diskrestore.sh)
again and again until it succeeds or the user aborts 'rear recover', cf.
https://github.com/rear/rear/pull/2249#discussion_r333018154

jsmeix commented at 2019-10-23 09:04:

With https://github.com/rear/rear/pull/2257 merged plus
https://github.com/rear/rear/commit/08f59566a968681771b64bfc5c791b34b8384cf5
I think this issue is solved as far as possible for me for now
and hopefully even without regressions.

I would appreciate it if ReaR users in particular those who
use BACKUP=TSM or BACKUP=NBU or BACKUP=GALAXY10
could test that changes as long as ReaR 2.6 is still under development
and report if there are regressions so that I can fix them,
preferably each one as a new and separated GitHub issue.


[Export of Github issue for rear/rear.]