[Bacula-bugs] [bacula 0000125]: Console run command splats the job resource when the Verify Job parameter is modified

[<bac...@li...>]

A BUGNOTE has been added to this bug.
======================================================================
http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000125
======================================================================
Reported By:                martin
Assigned To:                
======================================================================
Project:                    bacula
Bug ID:                     125
Category:                   Director
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
======================================================================
Date Submitted:             09-29-2004 08:37 PDT
Last Modified:              09-30-2004 02:40 PDT
======================================================================
Summary:                    Console run command splats the job resource when the Verify Job parameter is modified
Description: 
When runing a verify job from the console run command, the 'Verify Job' can
be modified, but the new setting persists in the defined verify job until
the Director is restarted.

Also, the run command has a verifyjob option which doesn't work.

I've attached a patch which fixes these things by adding a verify_job slot
to the JCR.  I didn't test the thoroughly with scheduled jobs however.

======================================================================

----------------------------------------------------------------------
 kern - 09-29-2004 12:40 PDT 
----------------------------------------------------------------------
Yes, you are right, there is a bug. However, from examining your patch
(unless I am mistaken, which is possible because reading patches gives
only a partial picture) you have introduced a more serious bug. That is
most people (probably 99.9%) use the verify Job field in the Job record to
run daily recurrent jobs. Your patch seems to exclude using that field. 

I propose the following:
- I'd like to take you patch but in a modified form.
- Please review your patch with what I said in mind, and either fix it as
noted
  below, or prove me wrong.
- I suggest modifying your code in verify.c to do two things: 1. Use the
jcr
  verify_job, only if it is set, otherwise use the value from the Job
record,
  if it is set. 2. Always clear the jcr verify_job field at the end of a
job
  or if the user does not start the job (i.e. answers no).

I think with the above, you will have corrected the bug without disturbing

the current way it works.

----------------------------------------------------------------------
 martin - 09-30-2004 02:40 PDT 
----------------------------------------------------------------------
Thanks for the comments.  I think my patch will already use the Verify Job
field in the Job record because it changes set_jcr_defaults() to
initialize jcr->verify_job from job->verify_job. Certainly when the Verify
Job field is set then it shows up as the default for the Verify Job
parameter in the console's run command, so I assume it will also be there
for scheduled jobs.

Checking job->verify_job in verify.c didn't look right because it would
make it impossible to override a non-null Verify Job field with a null
explicitly set in the jcr. Also, I think the code is cleaner if all
modifiable parameters are copied into the jcr before running the job (c.f.
store, client, fileset etc).

Bug History
Date Modified  Username       Field                    Change              
======================================================================
09-29-04 08:37 martin         New Bug                                      
09-29-04 08:37 martin         File Added: verifyjob.patch                    
09-29-04 12:40 kern           Bugnote Added: 0000325                       
09-30-04 02:40 martin         Bugnote Added: 0000328                       
======================================================================