Can uci store the cached changes somewhere else?

I am developing a script to make some changes via the uci command and then commit those changes.

But I am worried that if here are already unrelated uncommitted changes pending, that my 'uci commit' will inadvertently commit those pending changes as well as the ones I intend.

Is there a way to tell uci to store my uncommitted changes in a different directory, so they don't collide with any other pending uci changes?

I would have thought the -t option would do that, but -t appeared to make no difference.

I know I can "uci revert" at the beginning, but I'd rather have my own cache area.


I'm a bit confused about this...

Where else would the uncommitted changes come from except for you making those changes? Wouldn't you know about those changes?

Since you can issue the commits on a per-config file basis (i.e. network, firewall, dhcp, etc.), it would seem that you can avoid committing changes for the other files, and only commit the changes you are actively making anyway.

Here, if there are potential collisions, wouldn't it be important to know that at the time that you're making the changes? Imagine a situation where you make changes, commit them, and then some other commit undoes them or conflicts due to said collision. The commits should be one queue at a time... having multiple queues would be a recipe for disaster.

Wouldn't this make more sense? Or how about using uci changes to determine if there are any pending changes?

You could also approach it another way... your script that is writing the changes could also then use the uci changes at the end to verify that all of the requested changes are indeed pending, and that those are the only changes.

I don't see this option documented in the UCI user docs. Where did you see that as a valid option?

You're correct, it woud be me. But if the script I am talking about runs on cron, I could be in the middle of doing something interactively and the cron job hits and commits my incomplete changes. Probably a low probability, but I was looking to avoid the possibility.

Yes that would further reduce the probability.

I think this is the direction I should take.

From the built-in help of the tool. Typing "uci --help" in the shell includes the following:

        -p <path>  add a search path for config change files
        -P <path>  add a search path for config change files and use as default
        -t <path>  set save path for config change files
        -q         quiet mode (don't print error messages)

What would you be changing on a cron job? And how frequently is that cron firing? This could be bad for your system, and may be unnecessary. One of the few reasons to do this type of thing might be to change wifi credentials, but I can't really think of many other UCI elements that should be changed this way.

Meanwhile, maybe avoid making any changes to those files on the specific cron timings.

Better yet, make the script gracefully fail out if it detects any pending changes.

As I read this, it is the path for the actual final config file... not the UCI pre-commit staging. I think (although I could be wrong) that the UCI pre-commit staging happens in RAM. If you change the path of the final file, it won't work anyway (unless you then copy it into the right location, which still wouldn't solve your original concern).

The default directory where uci caches the changes is /tmp/.uci/

The -t option (available in version 22.03) does exactly what you want.

root@OpenWrt:~# uci get firewall.@ipset[0].enabled
root@OpenWrt:~# uci -t /tmp/pavel/ set firewall.@ipset[0].enabled='1'
root@OpenWrt:~# uci changes
root@OpenWrt:~# uci -t /tmp/pavel changes
root@OpenWrt:~# cat /tmp/pavel/firewall
root@OpenWrt:~# uci -t /tmp/pavel commit firewall
root@OpenWrt:~# uci get firewall.@ipset[0].enabled

I guess I stand corrected.

But I am curious if the way the op intends to use this feature may potentially create issues, or if it is safe to do this in general?

I don't see any potential problems, but to be honest I don't see any benefits either. I'm just answering the question " Can uci store the cached changes somewhere else?".


Wow, you're right. I could have sworn I tested the -t option and it had no effect.
But I retested and it works like it did for you.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.