1. 24 May, 2004 1 commit
  2. 22 May, 2004 3 commits
    • Tim Peters's avatar
      find_files(): When trying to do recovery to a time earlier than that · 988b5fa1
      Tim Peters authored
      of the most recent full backup, repozo.py failed to find the appropriate
      files, erroneously claiming
      
          No files in repository before <specified time>
      
      Repaired that.  Also made it much more robust against "junk files" the
      user may create, or leave behind, in the backup directory.  Added test.
      988b5fa1
    • Tim Peters's avatar
      New test for repozo.py. It doesn't run automatically, · 01b1f3f9
      Tim Peters authored
      but nothing in scripts/tests/ does.  It failed before the
      earlier (today) fixes to repozo.py, and passes now.
      Better Than Nothing -- which is what we had before.
      01b1f3f9
    • Tim Peters's avatar
      Foward port fix for race in DB.open(): · 516183b5
      Tim Peters authored
      Under exceedingly rare conditions, a timing hole made it
      possible for a second open() call on a database to block for an
      arbitrarily long time.  This accounts for the intermittent
      failure of a thread to make any progress after 5 minutes in
      checkConcurrentUpdates1Storage.
      
      We intend to get rid of most of this delicate lock
      business, but before then the test failures are still
      hurting me.
      516183b5
  3. 21 May, 2004 2 commits
    • Tim Peters's avatar
      · 1ccd62fd
      Tim Peters authored
      Collector #1330:  repozo.py -R can create corrupt .fs.
      When looking for the backup files needed to recreate a Data.fs file,
      repozo could (unintentionally) include its meta .dat files in the list,
      or random files of any kind created by the user in the backup directory.
      These would then get copied verbatim into the reconstructed file, filling
      parts with junk.  Repaired by filtering the file list to include only
      files with the data extensions repozo.py creates (.fs, .fsz, .deltafs,
      and .deltafsz).  Thanks to James Henderson for the diagnosis.
      1ccd62fd
    • Tim Peters's avatar
      The __future__ has arrived for generators. · 40fb2f29
      Tim Peters authored
      40fb2f29
  4. 19 May, 2004 2 commits
    • Tim Peters's avatar
      Collector #1208: Infinite loop in cPickleCache. · ab1f767a
      Tim Peters authored
      This fixes it, based on an approach suggested by Toby
      Dickenson.  The triggering condition wasn't entirely
      sane, so was very rare:  a persistent object with a
      __del__ method that referenced an attribute of self.
      
      scan_gc_items():  Look at persistent objects accessed
      while this is running at most once.
      
      New test checkMinimizeTerminates():  This spawns a thread
      that will in fact run forever if you don't recompile
      cPickleCache.c.  The test suite will keep running, but
      checkMinimizeTerminates will fail, and all future calls
      to cacheMinimize() will be effectively ignored (so other
      bad things may happen as a result).
      ab1f767a
    • Tim Peters's avatar
      checkFullSweep() and checkMinimize(): removed time.sleep(3) calls, and a comment block explaining · 47db2515
      Tim Peters authored
      why the sleeps are needed.  The explanation (and the
      sleeps) didn't make sense -- must be left over
      from a cache implementation before my time.
      47db2515
  5. 14 May, 2004 8 commits
  6. 11 May, 2004 3 commits
  7. 10 May, 2004 2 commits
  8. 07 May, 2004 1 commit
    • Tim Peters's avatar
      Collector 1309: ZODB.DB.DB.cacheExtremeDetail reports wrong reference count · a63883fd
      Tim Peters authored
      The refcount reported for a ghost was one too small, because the code for
      ghosts and non-ghosts was the same, and presumably "it's a feature" that
      the code for non-ghosts deliberately lies about the true Python refcount,
      in order (guessing here) to report what the count would have been if the
      cPickleCache didn't exist.  But while the cPickleCache holds on to a real
      reference to non-ghost objects, it does not hold a real reference to ghost
      objects, so subtracting "an extra" count for all objects made it appear
      that non-referenced ghosts exist in the cache (which doesn't actually
      happen).
      
      What a tangled web we weave ...
      a63883fd
  9. 05 May, 2004 4 commits
  10. 04 May, 2004 1 commit
  11. 03 May, 2004 11 commits
  12. 01 May, 2004 1 commit
  13. 30 Apr, 2004 1 commit