<p dir="ltr"><br>
On Mar 30, 2015 11:27 PM, "Yousong Zhou" <<a href="mailto:yszhou4tech@gmail.com">yszhou4tech@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On Mar 30, 2015 10:28 PM, "Mark Mentovai" <<a href="mailto:mark@moxienet.com">mark@moxienet.com</a>> wrote:<br>
> ><br>
> > In the latest OpenWrt trunk, I found that config_get has stopped loading uncommitted uci changes from /tmp/.uci. I rely on this behavior, which had worked well for years.<br>
> ><br>
> > I found a change[1] in uci that’s responsible.<br>
> ><br>
><br>
> Sorry for the inconvenience caused.<br>
><br>
> > The uci change makes uci_add_delta_path() reject any attempt to add ctx->savedir to the delta search path. However, in light of cli.c’s usage[2], there’s a problem: when processing a -P argument, it calls uci_add_delta_path() to add the original value of ctx->savedir to the delta search path before changing ctx->savedir.<br>
> ><br>
> > After this change, the uci command-line tool’s -P argument no longer acts as documented. Instead of adding a path to the delta search path, it just sets the default save directory.<br>
> ><br>
> > This behavior change appears to be unintentional, and as I mentioned, it’s broken a long-standing behavior that I rely on.<br>
> ><br>
> > This change became a part of OpenWrt at r45040[3] and is exposed to scripts that use /lib/functions.sh: that script sets LOAD_STATE=1, and its config_load calls /lib/config/uci.sh’s uci_load, which adds a -P argument to its “uci export” command when LOAD_STATE is nonempty.<br>
> ><br>
><br>
> Not yet with my keyboard at hand, will look into these scripts tomorrow.</p>
<p dir="ltr">I just sent a patch for this with you in the cc list.  Could you give it a try and tell if it can work for you?</p>
<p dir="ltr">cheers,<br>
                yousong</p>