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 ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
