wt., 3 gru 2019 o 14:27 Martin Simmons <mar...@lispworks.com> napisał(a):

> Is the current timing useful for some other situation?

I do not understand your question.

> It seems like a bug to me too.  To continue your analogy, it is like the
> restaurant forcing you to choose a dish when you book the table, before
> you've
> seen the menu of the day.

No, absolutely not. When you execute the copy job then all required data is
available and copy jobs simply start, so the menu is available when you
book a table.
But when you go to the restaurant then an admin stop you entering the room
and force you wait until the next day when menu changed - so it is not a
Admin should not prevent a copy job from executing. This is the main issue
here in the code which is currently available.

If you think it should work differently then you have to implement a
different kind of mechanism. And as I understand Heitor's answer the
solution is to link copy job with source job using Run=... directive. Then
your copy job will be executed when your source job finish.

Compare it with VolumeToCatalog verify jobs for example, which select the
> job
> when they start, not when they are scheduled.

Yes. This is exactly the same situation.

There is NO any link between source backup jobs and any Copy/Migrate/Verify
jobs (except the functionality described by Heitor), so it is impossible to
achieve what you request. It is how it was designed and implemented. You
could expect a different functionality so it should be designed and
developed. From a technical point of view we have to add another indirect
stage for job execution which will evaluate job execution parameters just
right before a real execution.

best regards
Radosław Korzeniewski
Bacula-devel mailing list

Reply via email to