Recent changes to bugs

DSToolkit is permanently disconnected if ZEO restarts

2005-01-21T13:51:46Z

As reported to the mailing list on 2005-01-04. Toby
says he can't reproduce with Zope 2.6.4. Might be a
ZODB bug?

I can reliably reproduce this on a fresh zope + zeo
instance
with zope 2.7.3 and a new DirectoryStorage (1.1.9).

How to reproduce:

0) create a zope + zeo instance (i.e. use
mkzopeinstance and mkzeoinstance; ok to use the same
directory for both).
Create a directory storage in the instance.

1) configure zeo.conf to use directorystorage:

%import DirectoryStorage
# Main DirectoryStorage database
<directorystorage main>
path $INSTANCE/var/DirStor
read-only off
</directorystorage>

2) configure zope.conf to use zeo:

<zodb_db main>
mount-point /
<zeoclient>
read-only off
server localhost:8100 # or whatever port

storage main
name zeostorage
var $INSTANCE/var
</zeoclient>
</zodb_db>

3) start zeo
4) start zope
5) confirm that everything works ok, i.e. navigate
around the ZMI a bit.
6) add a DirectoryStorageToolkit instance to zope

7) click on the DSToolkit - the management page should
come up ok

8) restart zeo. wait a few seconds for zope to
reconnect.
9) confirm that everything works - i.e. you can
navigate the
ZMI, add new objects, etc.
10) click on the DSToolkit instance. You get
DisconnectedError.

11) restart zope.
12) all is OK now including the DSToolkit.

AttributeError: 'None' object has no attribute 'group'

2003-03-17T11:33:05Z

This exception might be raised at startup (but with
different line numbers)

File
"/home/tdickenson/projects/DirectoryStorage/replica.py",
line 125, in prep_replica
self.fs.engage()
File
"/home/tdickenson/projects/DirectoryStorage/LocalFilesystem.py",
line 83, in engage
self._recovery()
File
"/home/tdickenson/projects/DirectoryStorage/LocalFilesystem.py",
line 296, in _recovery
if match.group(1)=='done':
AttributeError: 'None' object has no attribute 'group'

packing gives RuntimeError: maximum recursion depth exceeded

2003-01-17T11:49:01Z

On one of my bigger storages I have started seeing an error when
packing: RuntimeError: maximum recursion depth
Followed by a traceback of roughly 80 calls to
_mark_reachable_objects

The recursion limit is set to 1000, so why do we get this after roughly
80 calls?

lost+found

2003-01-14T13:13:05Z

It is currently impossible to recover from a crash which dumps files in
lost+found.

The best answer is to not use a filesystem where this is a possibility.
All recommended filesystems are safe from this.

One problem comes from 'current revision pointer' files. They dont
have enough redundant content to reconstruct their filename.

Can we reliably put files into the right journal directory to know
whether or not they had been commited?

backup.py exit codes

2003-01-06T08:49:05Z

The intention is that backup.py exit with a zero code
if and only if there is no problem.

backup.py contains:
if os.system('whatsnew.py|cpio|gzip>file'):
error(1)

But the shell discards the exit code of all except the
last command, gzip.

missing old files

2002-06-03T22:29:47Z

There are lost of places in the code that silently
ignore ENOENT errors when opening files. This could
mask bugs.

This is necessary because Full does not perform its
packing atomically. It is possible for one old file to
refer to another old file that does not exist, if
packing is aborted.

If packing was atomic the only two cross-file
references that needs this check for ENOENT are:
1. the object file's reference to his previous revision
2. the transaction file's reference to the previous
transaction.

Proposed resolution: keep track of the most recent pack
threshold time. raise an error if a file is missing
which dates from after this pack time.

cannot use with Solaris

2002-06-02T14:19:45Z

cannot use with Zope-2.5.1 for Solaris (dist by Zope corp).
on PosixFilesystem,

from posix import fsync, fdatasync

and abort by non existent "fdatasync".

I will more research and come back again later.
wait a moment.

file created by root

2002-05-31T15:19:15Z

z2.py start by root with "-u" option,
and storage files are created by root.

then, zope fallback to specified user of "-u" option,
and cannot read storage files. lock up.

cannot load additional product

2002-05-31T15:13:25Z

when install new (any) product, this exception raised.

2002-05-31T14:59:47 PANIC(300) z2 Startup exception
Traceback (innermost last):
File z2.py, line 497, in ?
File <string>, line 1, in ?
File /usr/share/zope/lib/python/Zope/__init__.py,
line 71, in ?
File /usr/share/zope/lib/python/OFS/Application.py,
line 418, in initialize
(Object: Zope)
File /usr/share/zope/lib/python/OFS/Application.py,
line 721, in install_standards
(Object: Zope)
File
/usr/share/zope/lib/python/App/FactoryDispatcher.py,
line 27, in __getitem__
File
/usr/share/zope/lib/python/App/FactoryDispatcher.py,
line 30, in __bobo_traverse__
File
/usr/share/zope/lib/python/App/ProductRegistry.py, line
157, in _getProducts
(Object: Zope)
AttributeError: Control_Panel

SHORT REASON: last oid lost when initialize BaseStorage.

AD-HOC SOLUTION: change BaseDirectoryStorage to below.

def __init__(self, filesystem, argv=None):
self.filesystem = filesystem
if argv:
self._main(argv)
else:
self._real_init()
oid = self._oid
BaseStorage.__init__(self, filesystem.name())
self._oid = oid

OR:

def __init__(self, filesystem, argv=None):
self.filesystem = filesystem
if argv:
self._main(argv)
else:
self._real_init()
BaseStorage.__init__(self,
filesystem.name(), self)