Interesting, since the pre/post-backup command runs in its own thread. Will test.

I just tested the pre-/post-backup commands in Vorta 0.6.10 and only the pre-backup command seems to freeze the UI. I assumed it extends to the post command as well, but it does not.

That makes sense actually. The pre-backup command is run when preparing the backup. So it runs in the main thread. (I gave the wrong info just before.)

The reason for this is to allow checking for certain conditions. E.g. the right network. If the returncode is not 0, it will cancel the backup.

I also noticed that the UI only blocks if the backup is started by the user. It doesn't block when the backup is started by the background scheduler.

So I see those options to improve the behavior:

1. Don't run pre-backup command when user starts backup himself + note about this next to the pre-backup field.
2. Add logging message that pre-backup command is now running before actually running it. So user knows whats going on. UI will still freeze.
3. Refactor to run pre-backup command in a separate thread, like the main Borg-command.

I wouldn't limit pre-backup to "checking conditions". Often this is used to bring the data into a backup-worthy state (like dumping an active database, doing a snapshot, etc.) and this obviously must always run, no matter whether started manually or automatically. So option 1 is out of question.

3 sounds like the best option.

3 it is then.

They are also uncancellable, while blocking other actions such as repo checking.

I would try to have an own PreBackupJob inheriting JobInterface or BorgJob and scheduling the BorgCreateJob in its finished_event method, while BorgCreateJob schedules the PostBackupJob. Though this is not as simple as I described it here since the jobs must run right after each other.

I have a pre backup script which takes a few minutes. It took me a while to realise that the UI had froze, without any notification that it was running.

I know in the long term it would be good to implement option 3. Would it be possible, for the short term, to implement option 2 as this would allow me (and other users) to see that the backup (and pre backup script) is running, while the UI is frozen.

Hi,
I'm working on this issue right now.