Le 05/12/2013 09:43, Johannes Raggam a écrit :
> On Don, 2013-12-05 at 15:42 +1000, Tom Cameron wrote:
>> 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.
Logiciels libres, hockey sur glace et autres activités cérébrales
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -