Menu
▾
▴
[Bacula-bugs] [bacula 0001737]: OneFS = no fails with multiple Options {} blocks
|
From: Mantis B. T. <no...@bu...> - 2011-05-19 08:29:12
|
A NOTE has been added to this issue. ====================================================================== http://bugs.bacula.org/view.php?id=1737 ====================================================================== Reported By: RoyK Assigned To: ====================================================================== Project: bacula Issue ID: 1737 Category: Director Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2011-05-18 18:20 GMT Last Modified: 2011-05-19 08:29 GMT ====================================================================== Summary: OneFS = no fails with multiple Options {} blocks Description: I had an fileset configuration like this the one given as non-working config in 'Additional Information' and OneFS = no was simply ignored. Combining the two Options {} blocks fixed this error. I don't know the code well enough, but can only guess that the second Options {} block took OpenFS's default value, 'yes', instead of the one set in the first block Steps to Reproduce: Just use the config below Additional Information: Non-working config FileSet { Name = "verdande.nilu.no-home-fileset" Include { Options { signature = MD5 OneFS = no FSType = zfs } Options { Exclude = yes WildFile = "*.mp3" } File = /tos-data/home } } Working config FileSet { Name = "verdande.nilu.no-home-fileset" Include { Options { signature = MD5 OneFS = no FSType = zfs Exclude = yes WildFile = "*.mp3" } File = /tos-data/home } } ====================================================================== ---------------------------------------------------------------------- (0005885) RoyK (reporter) - 2011-05-18 18:22 http://bugs.bacula.org/view.php?id=1737#c5885 ---------------------------------------------------------------------- I forgot a note - If this is the way it's designed to work, I beleive there should be a warning on the config checks, they don't say anything about two Options {} blocks today... ---------------------------------------------------------------------- (0005886) kern (administrator) - 2011-05-18 18:42 http://bugs.bacula.org/view.php?id=1737#c5886 ---------------------------------------------------------------------- "... can only guess that the second Options {} block took OpenFS's default value, 'yes', instead of the one set in the first block ..." Your "guess is correct, and it is also the way that Options blocks are designed to work. If you think about block structured syntaxes you will realize that the semantics of block structured languages limit the actions of values set in a block to the scope of that block. Sorry, but this is the way it is designed to work, and I don't see any reason to add a warning, because I believe the documentation is adequate. If the documentation is not adequate please send in a correction ... ---------------------------------------------------------------------- (0005887) RoyK (reporter) - 2011-05-18 18:50 http://bugs.bacula.org/view.php?id=1737#c5887 ---------------------------------------------------------------------- Reopening this to reply - it seems the code has a 'pass' variable that should be incremented per pass. I'm not sure if I understand sufficient of the code, but as far as I can see, this variable is checked before initialising the options structure, but I can't see it being incremented anywhere. roy ---------------------------------------------------------------------- (0005888) marcovw (developer) - 2011-05-19 07:47 http://bugs.bacula.org/view.php?id=1737#c5888 ---------------------------------------------------------------------- The parse logic is is in src/lib/parse_conf.c which contains the generic parser used for all daemons. If you look at line 903 of parse_conf.c you will see that it sets pass to 1 and 2 e.g. it first scans the config for all symbol names and then does an other pass and scans all items. Other then that I don't know much about the internals of the option parsing and I like to keep it that way, the only thing I normally need to know is how to extend it for new options. You also seem to think options are inherited and as far as I know they are not. Each new config section starts fresh with the same defaults not any new defaults made up in a previous block. For repeatable blocks like options you can have multiple entries and for the ones that are not specifying it twice it will use the second definition (e.g. the second definition overwrites the first). That is just the way it works. ---------------------------------------------------------------------- (0005889) RoyK (reporter) - 2011-05-19 08:29 http://bugs.bacula.org/view.php?id=1737#c5889 ---------------------------------------------------------------------- I see. I guess documenting this would be sufficient, then, something like 'If using more options blocks, following options blocks will overwrite the (above) settings with, first, default settings and then new settings? Logically, however, I would think re-applying the defaults in new Options blocks doesn't make much sens, but if it can't be changed easily, it should at least be well documented. roy Issue History Date Modified Username Field Change ====================================================================== 2011-05-18 18:20 RoyK New Issue 2011-05-18 18:22 RoyK Note Added: 0005885 2011-05-18 18:42 kern Note Added: 0005886 2011-05-18 18:42 kern Status new => closed 2011-05-18 18:42 kern Resolution open => no change required 2011-05-18 18:50 RoyK Note Added: 0005887 2011-05-18 18:50 RoyK Status closed => feedback 2011-05-18 18:50 RoyK Resolution no change required => reopened 2011-05-19 07:47 marcovw Note Added: 0005888 2011-05-19 08:29 RoyK Note Added: 0005889 2011-05-19 08:29 RoyK Status feedback => new ====================================================================== |