I think the best solution might be to add a crontab call during the 'apt-get install backintime' process if that is possible. That way it would only be called once, and it would be called immediately as soon as it is needed (without being dependent on any actions chosen by the user), and without giving the user any potentially confusing dialog windows to respond to?
On 18 Jul 2014 23:09, Germar <email address hidden> wrote:
>
> crontab doesn't run in userspace. It run as root and the user can only
> add new schedules with 'crontab' command. The schedules are stored
> somewhere in /var. That's why the schedules where gone after you
> reinstalled your system.
>
> BIT always set up crontab schedules as soon as you press OK in Settings
> dialog. No matter if they had change or not.
>
> We could add a warning on GUI start if crontab doesn't match BIT config
> and ask to run Settings.
>
> ** Changed in: backintime
> Status: New => Triaged
>
> ** Changed in: backintime
> Importance: Undecided => Medium
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1343599
>
> Title:
> Fresh install which picks up old settings does not set cronjob
> correctly
>
> Status in Back In Time:
> Triaged
>
> Bug description:
> If you have a nicely working instance of backintime successfully
> performing daily backups, and then you reinstall your operating-system
> (but preserve your home folder), followed by reinstalling backintime,
> then backintime nicely remembers its old settings.
>
> You can take a snapshot and it works as it did before. It all looks
> perfect - in fact it (incorrectly) reports that it is still scheduled
> to do daily backups. But strangely the daily backups do not happen,
> because the cronjob file was reset after the reinstall but the
> backintime settings were not reset - so the two do not match.
>
> I'm not sure what the solution to this problem is, other-than having
> backintime occasionally inspect the crontab file, e.g. whenever the
> backintime application is started. But I think this is a bug because
> back-in-time's settings panel is incorrectly stating that a daily
> backup schedule is set, and this gives a false sense of security.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/backintime/+bug/1343599/+subscriptions
I think the best solution might be to add a crontab call during the 'apt-get install backintime' process if that is possible. That way it would only be called once, and it would be called immediately as soon as it is needed (without being dependent on any actions chosen by the user), and without giving the user any potentially confusing dialog windows to respond to?
On 18 Jul 2014 23:09, Germar <email address hidden> wrote: /bugs.launchpad .net/bugs/ 1343599 /bugs.launchpad .net/backintime /+bug/1343599/ +subscriptions
>
> crontab doesn't run in userspace. It run as root and the user can only
> add new schedules with 'crontab' command. The schedules are stored
> somewhere in /var. That's why the schedules where gone after you
> reinstalled your system.
>
> BIT always set up crontab schedules as soon as you press OK in Settings
> dialog. No matter if they had change or not.
>
> We could add a warning on GUI start if crontab doesn't match BIT config
> and ask to run Settings.
>
> ** Changed in: backintime
> Status: New => Triaged
>
> ** Changed in: backintime
> Importance: Undecided => Medium
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Fresh install which picks up old settings does not set cronjob
> correctly
>
> Status in Back In Time:
> Triaged
>
> Bug description:
> If you have a nicely working instance of backintime successfully
> performing daily backups, and then you reinstall your operating-system
> (but preserve your home folder), followed by reinstalling backintime,
> then backintime nicely remembers its old settings.
>
> You can take a snapshot and it works as it did before. It all looks
> perfect - in fact it (incorrectly) reports that it is still scheduled
> to do daily backups. But strangely the daily backups do not happen,
> because the cronjob file was reset after the reinstall but the
> backintime settings were not reset - so the two do not match.
>
> I'm not sure what the solution to this problem is, other-than having
> backintime occasionally inspect the crontab file, e.g. whenever the
> backintime application is started. But I think this is a bug because
> back-in-time's settings panel is incorrectly stating that a daily
> backup schedule is set, and this gives a false sense of security.
>
> To manage notifications about this bug go to:
> https:/