On 11/26/2010 4:01 PM, Dan Langille wrote:
> On 11/26/2010 11:01 AM, Dan Langille wrote:
>> On 11/26/2010 2:41 AM, Eric Bollengier wrote:
>>> Hello Dan,
>>>
>>>
>>> On Friday 26 November 2010 04:53:52 Dan Langille wrote:
>>>> Background: A copy/migrate job has at least two Volumes:
>>>>
>>>> * the Volume[s] for the original Job (at least one)
>>>> * the Volume[s] for the new Job (i.e. Copy/Migrate) (at least one)
>>>>
>>>> My problem: When a copy/migrate job includes a RunAfterScript, the %v
>>>> parameter passed into the script is *always* the source Volume; the
>>>> destination Volume cannot be passed in. This means the script cannot
>>>> know the destination volume, which is something I want.[1]
>>>>
>>>> Proposal: add a %V (capital V) option to edit_job_codes in lib/util.c
>>>
>>> I agree, this is a nice addition.
>>>
>>>> Issue: The volume name we need is contained in mig_jcr, which is created
>>>> within migration_cleanup(). I know this based upon the job output (see
>>>> below)[2][3]
>>>>
>>>> My initial attempt failed. See the attached patches. The problem I
>>>> encountered may not be related to the patch. The tape was having a seek
>>>> problem (which has since gone away after switching to a new tape and
>>>> restarting the tape library). If the feedback here indicates I should
>>>> try again, I will. I first want to ensure I'm not taking the wrong
>>>> approach.
>>>
>>> We have a callback mechanism that permits to add per daemon job code
>>> variables, so instead of modifying the edit_job_code(), you can add specific
>>> variables to the Director in dird_conf.c job_code_callback_filesetname()
>>> (it's
>>> a good idea to change the callback name to something less specific).
>>
>> Ugh. It appears to be a dead end. jcr->mig_jcr has no value in
>> job_code_callback_filesetname(), thus, we can't grab the right Volume name.
>
> Off list, Eric and I spoke via IRC regarding this issue. I now know why
> jcr->mig_jcr has no value. The clearing occurs in src/dird/migrate.c
> migrate_cleanup():
>
> if (jcr->mig_jcr) {
> free_jcr(jcr->mig_jcr);
> jcr->mig_jcr = NULL;
> }
>
> If we comment out this code, which is not the ideal solution, amended
> job_code_callback_filesetname() works.
>
> Perhaps an ideal solution involves clearing jcr->mig_jcr within
> src/lib/jcr.c b_free_jcr(), but my initial attempts there fail:
>
> if (jcr->mig_jcr) {
> b_free_jcr(file, line, jcr->mig_jcr);
> jcr->mig_jcr = NULL;
> }
>
> because:
>
> jcr.c: In function 'void b_free_jcr(const char*, int, JCR*)':
> jcr.c:492: error: 'class JCR' has no member named 'mig_jcr'
>
> Again, bitten by the #ifdef....
>
> But... progress is being made. :)
Perhaps we are approaching this incorrectly.
jcr is one job.
jcr->mig_jcr is another job.
Why isn't the run script being started from the migration job? That job
would have all the required information.
--
Dan Langille - http://langille.org/
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
