DECISION: what reconstruct -f should do

[Joost Roeleveld]

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 
using cyradm.

Would a second flag, for instance "--full-dir-tree" (or similar), to change the 
behaviour to create the directory regardless work?

-- 
Joost