When you emerge zope, it does a default zope installation... without checking to see first if you perhaps had some data in your installation you may have wanted. It either needs to 1) check first or 2) tell the user the command to setup an install, rather than doing it itself Reproducible: Always Steps to Reproduce: 1. emerge zope 2. mess with zope 3. emerge zope Actual Results: Your changes are gone. Expected Results: Something other than deleteing your changes.
zope stuff belongs to kutsuya not PHP!
It could be good to have a way to make a ZODB backup whne it uninstalls, and a ZODB recovery when it installs as an upgrade. Protecting of db files is also a good idea, but it's not enough sometimes (between some versions) and the backup-recovery scenario will be required then
what are the files that have to be saved?
*** Bug 35388 has been marked as a duplicate of this bug. ***
Sorry for the dup. Another (probably easiest) solution is to install mv ${ZINSTDIR}/Data.fs to Data.fs.dist in src_install(). This way the previously-installed (and modified) copy is not overwritten, but you still get a new, pristine copy if you need to have it for some reason. Additionally, there should probably be a note in pkg_postinstall() that Data.fs.dist needs to be copied to Data.fs, or perhaps do this automatically if Data.fs does not exist.
The problem lies within zope-config: zinst_fs_setup() is what does the clobbering.
fixed in zope-config-0.3 :)
There's a possible issue with zope-config-0.3. It now copies Data.fs, if it exists, to Data.fs.org, copies over the template data (include the pristine Data.fs), and then moves Data.fs to Data.fs.dist, and Data.fs.org to Data.fs. The problem here is, if Zope is running, then it will have Data.fs open. Data.fs.org will be a copy, and then it will be moved into place over the open Data.fs, which will have a link count of 0 and be deleted once it is closed. If something is written to Data.fs after it is copied but before Zope is shut down, that data will be lost, because it will be written to the unlinked file. The solution is, use mv instead of cp. It'll be renamed, but any running Zope will still have the file open, and it'll end up where it started. Alternately, zope-config could refuse to install anything if the target directory already exists.
ok, changed to mv :)
