Bugzilla Bug 29705

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 :)