[asterisk-bugs] [Asterisk 0008684]: [patch] Fix bad handling of #include directives from manager GetConfig/UpdateConfig

noreply at bugs.digium.com noreply at bugs.digium.com
Wed Aug 29 15:41:15 CDT 2007


The following issue has been CLOSED 
====================================================================== 
http://bugs.digium.com/view.php?id=8684 
====================================================================== 
Reported By:                ssokol
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   8684
Category:                   Core/Configuration
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.0 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
Resolution:                 open
Fixed in Version:           
====================================================================== 
Date Submitted:             12-28-2006 10:28 CST
Last Modified:              08-29-2007 15:41 CDT
====================================================================== 
Summary:                    [patch] Fix bad handling of #include directives from
manager GetConfig/UpdateConfig
Description: 
Currently the configuration parser used to process GetConfig/UpdateConfig
manager commands follows the standard rules for reading configuration
files: it reads until it hits a directive (#include or #exec).  When it
hits a directive, it loads the included or executed file, then continues
with the original.  Unfortunately, it does not retain any knowledge of the
directive (i.e. it has no idea that a portion of the config data was added
due to a #include).

This makes no difference when the config file is being read for the sake
of the actual running configuration, but it presents a problem for the
GetConfig and UpdateConfig manager commands.  When the UpdateConfig command
goes to save the altered version of the configuration, it has no idea that
a portion of the config data was actually inserted from another file.  Thus
all of the data gets written back to the original file and the #include
command disappears.

The attached patches avoid this issue by forcing the configuration parser
to ignore any #include directives.  The load command simply treats them as
comments so that they are retained and written back out during the save
step.
====================================================================== 

---------------------------------------------------------------------- 
 murf - 08-29-07 15:41  
---------------------------------------------------------------------- 
I merged the fix into 81361 in trunk; I could do it to 1.4, if this is
generally considered a bug fix vs. an enhancement.  What I said:

"This code was in team/murf/bug8684-trunk; it should fix bug 8684 in
trunk. I didn't add it to 1.4 yet, because it's not entirely clear to me if
this is a bug fix or an enhancement. A lot of files were affected by small
changes like ast_variable_new getting an added arg, for the file name the
var was defined in; ast_category_new gets added args of filename and
lineno; ast_category and ast_variable structures now record file and lineno
for each entry; a list of all #include and #execs in a config file (or any
of its inclusions are now kept in the ast_config struct; at save time, each
entry is put back into its proper file of origin, in order. #include and
#exec directives are folded in properly.  Headers indicating that the file
was generated, are generated also for each included file. Some changes to
main/manager.c to take care of file renaming, via the UpdateConfig command.
Multiple inclusions of the same file are handled by exploding these into
multiple include files, uniquely named. There's probably more, but I can't
remember it right now."

Re-open this issue if there are problems, or open a new one... it's up to
you.

murf 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-29-07 15:41  murf           Status                   assigned => closed  
08-29-07 15:41  murf           Note Added: 0069660                          
======================================================================




More information about the asterisk-bugs mailing list