Kern Sibbald wrote: > Hello Phil, > > I can understand your point, but I still don't consider this a bug. The > deficiency has been there quite a long time (I have been wondering when > someone > would complain about it).
Well, in this case, though I upgraded my Bacula installation quite a while ago, I only recently got a working tape drive again and started trying to test a configuration in which it became an issue. It was the first I'd ever run into it, or I would have brought it up sooner. > I am not even sure how one might go about > resolving the problem: > > 1. Make manually overriding the Pool when starting a Job take precedence over > all other Pool specifications? I don't particularly like that idea. It seems to be to be the obvious approach. If I'm starting a job manually and choosing to manually override the Pool, then that override should be honored - period - because if I, as a Bacula administrator, choose as a conscious and separate manual operation to override the Pool for a job I'm about to manually start, the odds are pretty high that I have a good reason for doing so. If a manual override does NOT override other Pool specifications, then what's the point of having a manual override for the Pool? It's rather inherent in the concept of having a manual override. As a thought experiment: Can you think of a real-world scenario in which one could conceivably want a manual override of any job setting, in a job manually started by the Bacula administrator, NOT to be honored? I can't. > 2. Add several new commands that allow overriding all the different Job level > pool directives? I don't much like that either. I agree that would be a bad approach. If I want to override the Pool on a manual job, I shouldn't have to second-guess the software and jump through multiple hoops just to keep it from finding ways to do something different from what I just specifically told it to do. The whole point of having manual overrides - or being able to issue console commands at all, for that matter - is to be able to interactively tell the software, when needed, to do something other than what it would automatically do if left to itself. > Anyway, until I find something I really like and time to implement it will > remain their -- unless, of course, someone sends a reasonable patch. I'll put it on my list of things to look at once I finish getting my workstation updated and reinstalled. (I've finally gotten the hardware issues solved, and I'm down to just one or two unsolved issues with the last remaining crucial program that I needed to write a replacement for. I'm fairly sure both are Tk-related problems.) -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 [email protected] [email protected] [email protected] Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
