Comment 14 for bug 191681

It would be another very easy way to handle the way of getting control over this problem:
I think some of people out there, that are doing backups had these problems using external drives. I am using simple lock files on the backup drive to recognize if a certain drive or directory is mounted or not. Another way is the evaluation of the UUID of a mounted drive as mentioned above.

However, thinking for advanced users and the possibilities of scenarios in general: Add an option to execute a script before/after timevault starts a scheduled backup.

This will give the user / admin full control over the backup-process, mounting, unmounting, preparing of backup drives (e.g. dvdrw's) ... It will be possible to add timevault in a more complex backup chain. Scripts might be written in different languages.

Timevault should evaluate the return code of the "before"-script as followed:
 0 - (scheduled) backup will be proceeded / no error
 1 - (scheduled) backup will NOT be executed / no error message**
 2 - (scheduled) backup will NOT be executed / error message to the user and a simple log entry "script execution failed"

** this is for automated backups when the user does not want to be informed, because he knows what he is doing (e.g. switches on the external usb backup drive manually).

The "after"-script return code should be evaluated like this:
 0 - do nothing
 1 - give an error message / log entry.

For you, the developer this should be a one-liner in the code. If you like to hide this option for the average user, you could simply enable script execution via /etc/timevault.conf :
 'executeBefore': '/root/timevault/before.sh',
 'executeAfter': '/root/timevault/after.sh',

Greets Axel