http://www-uxsup.csx.cam.ac.uk/~dpc22/cyrus/patches/2.3cvs/
unexpunge-since.patch
=
Finally got fed up interpreting unexpunge -l with magic sed scripts.
Here's a patch which adds a -t time-interval argument, so that:
unexpunge -t 24h user/dpc22
restores everything
Looking (again) at integrating this. Two observations, the first
somewhat minor, and the second somewhat major:
- statuscache v.2 doesn't have support for HIGHESTMODSEQ. This is
trivial to add to a v.3.
- statuscache v.2 stores statuscache_data as a binary blob, which is
platform
Bron Gondwana wrote:
On Thu, Jan 17, 2008 at 02:47:27PM -0500, Ken Murchison wrote:
Looking (again) at integrating this. Two observations, the first somewhat
minor, and the second somewhat major:
- statuscache v.2 doesn't have support for HIGHESTMODSEQ. This is trivial
to add to a v.3.
- statuscache v.2 stores statuscache_data as a binary blob, which is
platform dependent (byte-order word size). This make statuscache.db
non-portable. I believe that this might be the first cyrusdb that would
be non-portable. Does anybody care?
The only tricky part is going to be
Rob Mueller wrote:
Basically our startup scripts completely delete the statuscache.db file
on startup, so migrating isn't an issue for us at all.
Why do you delete the cache? I doesn't appear from the code that the
cache entries would be invalid if the mailbox and seen state aren't touched.
Why do you delete the cache? I doesn't appear from the code that the
cache entries would be invalid if the mailbox and seen state aren't
touched.
Historical. We only use berkeley db for statuscache and duplicate delivery,
and because of problems in the past with berkeley db's corrupting
Here's my modified patch against CVS. I suppose some code could be
added to statuscache_lookup() to read both v.2 and v.3. There isn't any
reason to invalidate all v.2 caches just because they don't have
highestmodseq
--
Kenneth Murchison
Systems Programmer
Project Cyrus
