-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Simmons wrote:
>>> Actually to give credit where it is due, Martin supplied the patch (many
>>> thanks). I forget if he sent an email or a submitted a bug report, but if
>>> I
>>> remember right his fix was for 1.38.11, but since 1.39.x is so close, I
>>> only
>>> applied it to 1.39. I mention this just in case you really need the fix
>>> and
>>> don't want to upgrade to 1.39 yet, which is still BETA.
>> That I did know -- he did send an e-mail; I guess my thank you was to
>> the community.
>>
>> I would be interested in patching my director to support this, to a
>> certain extent, as I'd imagine it was a fairly trivial patch (at least
>> in the sense of how many lines/files changed -- possibly not in
>> intricacy. Is it freely available somewhere (perhaps Martin can chime in)?
>
> This is the patch I have been using in 1.38.11:
>
> --- src/dird/ua_status.c~ Tue Mar 14 21:41:40 2006
> +++ src/dird/ua_status.c Fri Oct 27 11:56:37 2006
> @@ -380,9 +380,12 @@
> close_db = true; /* new db opened, remember to close it
> */
> }
> if (ok) {
> + STORE *old_jcr_store = jcr->store;
> mr.PoolId = jcr->PoolId;
> mr.StorageId = sp->store->StorageId;
> + jcr->store = sp->store;
> ok = find_next_volume_for_append(jcr, &mr, 1, false/*no create*/);
> + jcr->store = old_jcr_store;
> }
> if (!ok) {
> bstrncpy(mr.VolumeName, "*unknown*", sizeof(mr.VolumeName));
I have found out what the problem is here on my setup. This apparently
works so that Storage devices that are on the Schedule are not taken
into account when reading 'status dir'. My problem is a little different
than this and therefore is not solved by this patch.
My issue with status dir is that it does not take into account the
"Incremental Pool" or "Full Pool" or what have you. If you have these
defined, 'status dir' only looks at the pool that is defined, even
though it knows it will be running an Incremental job, for example. I
can't have pool defined as both my incremental and my full pool, so I
usually choose the full pool. When I run 'status dir', I see all of my
jobs are going to request tapes from the full pool, when really they are
not.
My solution so far has been having the base pool for the jobs set in
such a way that every pool is covered. The operator (or usually me) has
to then realize, OK, I have to look at the scheduled job that shows an
incremental tape, and that is the next tape for all of the backups that
are scheduled incremental. I'd love it if this data were actually
accurate, but I don't know how to fix it myself.
=R
- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFeFfxmb+gadEcsb4RAsF8AKCLkeOGmMdQtgvMGXba/H+oqu9ZvwCgpKge
t2H48+qzMWRx0eyNpQFfzF8=
=ekEK
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
