From: <bac...@li...> - 2004-09-30 09:36:55
|
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 ====================================================================== |