Le 05/12/2013 09:43, Johannes Raggam a écrit :
On Don, 2013-12-05 at 15:42 +1000, Tom Cameron wrote:
Questions My main aim is to work out what happened. My best guess is that Zope was somehow connecting to a stale or outdated file pointer and updating that file all along while the Data.fs was pointing to an August 5 copy. But how could this situation eventuate and persist for so long? for my, it looks exactly like that Zope used an inode, which wasn't the Data.fs you expected. It used that as long as you restarted Zope. your backups were always copying the old Data.fs from the filesystem path, where you expected the correct one to be in.
that happens, when the directory with your Data.fs is moved (e.g. $ mv ./var ./var-bak) and a new one copied back to the old place (e.g. $ cp -R ./var-bak ./var).
that happens also, when the Data.fs is deleted.
I'm agree with this description. You can test this python behavior in a python shell: when a file is unlinked in the filesystem (move or deleted) python move the file descriptor into RAM and still use it there without warning. The file descriptor is destroyed when the python process end (Zope stop or restart). Your only way is to find a Data.fs.old from the last pack somewhere or to have a backup. -- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales