[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