1. 23 Mar, 2000 1 commit
  2. 22 Mar, 2000 3 commits
  3. 06 Mar, 2000 1 commit
  4. 11 Jan, 2000 1 commit
  5. 10 Dec, 1999 2 commits
    • Jim Fulton's avatar
      Fixed a bug in commiting or discarding versions. Some undone transactions · 04894d01
      Jim Fulton authored
      were not handled correctly.
      04894d01
    • Jim Fulton's avatar
      On systems where the fsync system call is available, we now call · fbde45ad
      Jim Fulton authored
      fsync when commiting transactions to make sure that transaction
      data are written to physical storage immediately. There is circumstantial
      evidence that database corruption has been caused due to problems with
      delayed write of data after Zope has flushed transaction data.
      
      Added logic to avoid writing empty transactions. It's imaginable that
      some future application might want to write empty transactions to
      capture transaction meta data. If this ever becomes an issue, then
      this feature would have to be made optional.
      fbde45ad
  6. 09 Dec, 1999 2 commits
    • Jim Fulton's avatar
      initial version · 8bff3c4e
      Jim Fulton authored
      8bff3c4e
    • Jim Fulton's avatar
      Added flush call in undo. · 039bcfc0
      Jim Fulton authored
      Added utility code to recover corrupted databases. Note that
      the recover method is imperfect. It doesn't recover lost data. It
      just repairs the file so the lost data doesn't prevent startup.
      
      To run the recovery code:
      
        - cd lib/python
        - python ZODB/fsrecover.py ../../var/Data.fs
      039bcfc0
  7. 07 Dec, 1999 1 commit
    • Jim Fulton's avatar
      The following scenario could lead to strange and serious errors: · 58d0299a
      Jim Fulton authored
        - Restart or pack Zope, causing an index to get written
      
        - Undo some transactions
      
        - Shutdown Zope ungracefully (e.g. kill)
      
      When Zope comes up, the index points to undone records for some
      objects. This can lead to all sorts of problems. :(
      
      To overcome this problem, we now remove the index after an
      undo.
      
      This increases the likelyhood that it will take longer to restart
      next time, but reduces the chance of a bad index.
      58d0299a
  8. 23 Nov, 1999 3 commits
  9. 16 Nov, 1999 13 commits
  10. 12 Nov, 1999 1 commit
  11. 10 Nov, 1999 1 commit
  12. 28 Oct, 1999 1 commit
    • Jim Fulton's avatar
      Somehow, someone got a zero previous record pointer on a record for an · 11858d5b
      Jim Fulton authored
      object that has previous records.  This caused a panic on startup
      because the previous record pointer did not agree with the system's
      knowledge that there was, indeed, a previous record. This is a
      pretty benign situation, so, I've changed the check to log a warning
      of the previous record pointer is zero and there is a previous record.
      11858d5b
  13. 22 Oct, 1999 1 commit
  14. 18 Oct, 1999 3 commits
  15. 13 Oct, 1999 1 commit
  16. 07 Oct, 1999 5 commits