Hi everybody, I looked around the Zope site and mailing lists, but I wasn't able to find an answer to my problem. I'm using the CVS version of Zope2. I did an update yesterday. Since then, there's been some commits. I just started my web site project using Zope running with ZServer, when I began to have problems doing Cut-Paste operations. I thought at first that I messed the permissions or something because of my lack of experience with Zope. Little did I know at that moment that my Data.fs was corrupted very badly. So I tried to restart Zope, but it refused giving me this backtrace: [zope@petechie ~/Zope2]$ ./start Traceback (innermost last): File "/home/zope/Zope2/z2.py", line 554, in ? exec "import "+MODULE in {} File "<string>", line 1, in ? File "/home/zope/Zope2/lib/python/Zope/__init__.py", line 110, in ? DB=ZODB.FileStorage.FileStorage(Globals.BobobaseName) File "/home/zope/Zope2/lib/python/ZODB/FileStorage.py", line 303, in __init__ self._pos, self._oid, tid = read_index( File "/home/zope/Zope2/lib/python/ZODB/FileStorage.py", line 1515, in read_index if read(4) != packed_version: raise FileStorageFormatError, name ZODB.FileStorage.FileStorageFormatError: /home/zope/Zope2/var/Data.fs I then logged to Zope web site to get information on how to get my Data.fs fixed. I read the http://www.zope.org/Members/itamar/CorruptedZODB document and downloaded the tranalyzer.py python program. I then understood what the backtrace already told me. The first 4 bytes of any ZODB files should be something like "FS21". Instead, I have garbage in my Data.fs: [zope@petechie var]$ python tranalyzer.py Data.fs | more Traceback (innermost last): error: Not a .fs file (at least, not a kind I know about) magic = 6TÆ Just for the record, Data.fs.in is read easily by tranalyzer.py. How can this happen? Any idea? My only "guess" is that it has to do with the Data.fs file being used by ZServer over an NFS partition on Linux. This is only a guess, but I really can't see any other thing I could have done wrong. This doesn't really bug me for the moment as I only had a couple of hours put in my site, but I would like to prevent it from happening again.... yes I do backups, but only once a day ;-) Thanks for your help/comments. Carl Carl Robitaille robitail@giref.ulaval.ca
On Wed, Aug 09, 2000 at 05:52:10AM +0000, Carl Robitaille wrote:
How can this happen? Any idea? My only "guess" is that it has to do with the Data.fs file being used by ZServer over an NFS partition on Linux. This is only a guess, but I really can't see any other thing I could have done wrong.
Ai, NFS! There is a known no-no about using NFS for Data.fs storage, it leads to data corruptions. Zope and NFS do not mix. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | ZopeStudio: http://www.zope.org/Products/ZopeStudio -----------------------------------------------------
Hi, Thanks a lot for your quick response.
On Wed, Aug 09, 2000 at 05:52:10AM +0000, Carl Robitaille wrote:
How can this happen? Any idea? My only "guess" is that it has to do with the Data.fs file being used by ZServer over an NFS partition on Linux. This is only a guess, but I really can't see any other thing I could have done wrong.
Ai, NFS! There is a known no-no about using NFS for Data.fs storage, it leads to data corruptions. Zope and NFS do not mix.
I thought I read enough about Zope to begin working, but it seems I still have some reading to do. Good guess on my part though for the NFS thing! ;-) Hope this post keeps other people from doing the same mistake. Thanks again. Carl
Carl Robitaille wrote:
Hi everybody,
I looked around the Zope site and mailing lists, but I wasn't able to find an answer to my problem.
That's because your problem only existed for a few hours. Sigh.
I'm using the CVS version of Zope2.
We try to keep this stable, but no guarantees. Some changes were checked into CVS on Monday night that caused the problem you observed.
I did an update yesterday.
Unlucky you. :/
Since then, there's been some commits.
(snip) Copy/paste (export/import) were broken and led to database corruption. I checked in the fix to this yesterday.
I then logged to Zope web site to get information on how to get my Data.fs fixed. I read the http://www.zope.org/Members/itamar/CorruptedZODB document and downloaded the tranalyzer.py python program. I then understood what the backtrace already told me. The first 4 bytes of any ZODB files should be something like "FS21". Instead, I have garbage in my Data.fs:
Right. The bug caused the file pointer to get incorrectly set at 0, so transactions after the copy/paste errors were written at the beginning of the file.
[zope@petechie var]$ python tranalyzer.py Data.fs | more Traceback (innermost last): error: Not a .fs file (at least, not a kind I know about) magic = 6TÆ
Just for the record, Data.fs.in is read easily by tranalyzer.py.
How can this happen? Any idea?
I think I answered that.
My only "guess" is that it has to do with the Data.fs file being used by ZServer over an NFS partition on Linux. This is only a guess, but I really can't see any other thing I could have done wrong.
It was a software bug, which has been fixed.
This doesn't really bug me for the moment as I only had a couple of hours put in my site, but I would like to prevent it from happening again.... yes I do backups, but only once a day ;-)
It shouldn't happen again. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Hi,
That's because your problem only existed for a few hours. Sigh.
I'm using the CVS version of Zope2.
We try to keep this stable, but no guarantees. Some changes were checked into CVS on Monday night that caused the problem you observed.
That's all right. I'm just an unlucky bastard, that's all ;-)
Right. The bug caused the file pointer to get incorrectly set at 0, so transactions after the copy/paste errors were written at the beginning of the file.
Thanks for the info. Carl
participants (3)
-
Carl Robitaille -
Jim Fulton -
Martijn Pieters