DECISION: what reconstruct -f should do
joost at antarean.org
Wed Apr 27 02:19:10 EDT 2011
On Tuesday 26 April 2011 10:19:36 David Lang wrote:
> On Tue, 26 Apr 2011, Bron Gondwana wrote:
> > On Sat, Apr 23, 2011 at 01:07:00AM +0200, Bron Gondwana wrote:
> >> 3) add the mailbox if there's a directory, don't require
> >> cyrus.header.
> >> 4) like (3) - but check that there's at least one cyrus.* file
> >> OR at least one message file in the directory before
> >> creating the mailbox. (so an empty directory doesn't generate
> >> a bogus mailbox, and neither does one containing nothing that
> >> looks like it belongs in a mailbox)
> > The clear winner appears to be (3) - the suggestion of adding
> > yet-another-switch[tm] seems a bit silly to me, you're already
> > specifying -f which pretty much means "I'm recovering from something
> > that got the filesystem out of sync with mailboxes.db".
> > But - there was one valid concern. Assuming this structure:
> > $conf/user/foo/
> > $conf/user/foo/[contents]
> > $conf/user/foo/sub/
> > $conf/user/foo/sub/folder/
> > $conf/user/foo/sub/folder/[contents]
> > It's legal for the following to exist:
> > INBOX
> > INBOX.sub.folder
> > Without INBOX.sub
> > So I'm going to implement a modified (3) as follows:
> > a) if cyrus.header, it's a folder
> > b) if spool files, it's a folder
> > c) if a directory with no subdirectories it's a folder
> > Otherwise it's an intermediate folder, so we recurse without
> > creating a mailboxes.db entry. Basically, (4) but still
> > creating leaf folders, just not intermediate ones that don't
> > have any other content.
> I can easily see someone wanting to have INBOX.sub containing
> INBOX.sub.folder1 and INBOX.sub.folder2 as an organizational mechanism
> if you were to create INBOX.sub and the user didn't want it, could they
> remove it without affecting INBOX.sub.folder?
> if you don't create INBOX.sub and the user wants it, will they run into any
> grief when they try to create INBOX.sub due to the fact that the directory
> already exists?
In my experience, most IMAP-mail clients have problems inserting the
"INBOX.sub" folder. In these cases we'd probably need to do this manually
Would a second flag, for instance "--full-dir-tree" (or similar), to change the
behaviour to create the directory regardless work?
More information about the Info-cyrus