When the firmware is upgraded (Eg. 3.0.0 to 3.0.1, or 3.0.1 to 3.0.2b1, etc.) I am interested in which files/directories are overwritten.

For example, If I have added a new script to /www/cgi-bin will the entire directory be overwritten, or just the files matching those in the new release?  In particular, I am interested in /usr/local/bin, /www and /etc.

As a corollary to that question, is there a particular location where I can place my own data, code, etc that will survive updates and never be overwritten?

BTW, I am assuming that any standard files I have modified will have to be re-installed after an upgrade.

Thanks

Today, everything gets wiped upon an update.

That will change soon on Ubiquiti (where we have more memory and newer OpenWRT support.

Darryl

Thanks.  Even a single directory structure would be great. I could then symlink or copy from there as needed and I could easily script that!

Actually under the current develop tree code it is still intended to wipe everything from a program standpoint, only node configuration data will be attempted to be retained.

I haven't heard of any plans to change this as all the arguments are basically against this as each version  upgrade could create a potentially disastrous incompatibility in programs currently installed on a node the only safe way is to do a full wipe and require reinstall of packages after the node is up and running.

I can understand the reasoning for a clean install on a major version upgrade. However, if you want to encourage people to test the beta releases, then this could be a show stopper. If there were just one directory in the file system that would remain untouched, like maybe /var/local, then I could either add that to the search path in scripts, or symlink to it.

It would, of course, have to be made well known that programs and files stored under /var/local might not operate properly after a firmware upgrade. I suspect that those user who would take advantage of such a feature would be those more likely to understand how to use it.

I think the disastrous incompatibility argument is also sort of moot. What difference does it make if I store my data, code, etc. on the node or transfer it to the node after the upgrade.  The incompatibility issue remains the same, regardless of where the files are stored.