DECISION: what reconstruct -f should do

[David Lang]

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?

Daivd Lang