On 2006-11-14 at 17:57 +0100, Marten Lehmann wrote:
> ok, good point. I haven't worked with Shared Folders yet, but how and
> where are flags stored then? Isn't the global flag what you want? If I'm
Depends upon the flag. Seen state is one that's kept per-user and
that's in a separate file under {configdirectory}/user/...; see also
seenstate_db in imapd.conf.
Various other state is kept in "cyrus.index". The per-message flags are
all shared (I think, but could be wrong). The folder flags set via
annotatemore (now called folder metadata) can be shared or private and
are stored in {configdirectory}/annotations.db; you need that too if
dumping/restoring a mailbox.
Arbitrary user-defined flags can be set, so a DB is the right place.
Eg, the mutt developers decided that because there are so many poor IMAP
servers they're now relying upon being able to store the custom "Old"
flag to decide which mails are old (this is -devel branch). Encoding
arbitrary strings into filenames means that you then end up looking at
what happens to the filesystem driver's caching of directory entries
with long names. Having all your filenames not be able to go into a
lookup hash is generally a bad move. ;^)
Another issue if considering changing a current system is what other
factors are going to be affecting the protocol and software in the same
timeframe. One of the IMAP extensions in draft is the ANNOTATE
extension which allows storing per-user arbitrary metadata per email,
with those items being optionally either shared or private; the data
model is very similar to that used by Cyrus imapd now for the folder
annotations. So moving towards encoding data in filenames, to make it
easier to preserve, is a step backwards.
> But I think rename()s are very cheap.
If there's not much contention for the directory, they are. If you have
a shared directory being accessed by various servers, eg with a
clustered filesystem, they're still fairly cheap individually but in
aggregate they become a bottleneck as the directory needs to be updated
atomically. And with some people looking towards NFSv4, in the hope
that Berkeley DB is safe on it, having one client setting a flag blowing
away the directory cache on other servers in a cluster is not a good
plan.
> Anyway: I still don't have a working solution to backup and restore
> mails including flags. Shouldn't this be a point especially on large
> environments where the whole company mail traffic runs through IMAP so
> the administrators can more easily backup mails on the servers than they
> could by backing up the mailfolders on the client computers?
If you back up the cyrus.index file too, and the relevant stuff under
configdirectory, then unless the file ends up corrupted the
reconstruct(8) command can work with it.
There has been work on exported dump tools to improve the situation.
There is cyrdump, which will dump the information. Now all that's
needed is cyrrestore. ;^) I suspect that contributions towards that
would be welcome.
-Phil
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
