Re: DECISION: what reconstruct -f should do
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/
Re: DECISION: what reconstruct -f should do
On Wed, Apr 27, 2011 at 10:31:40AM +0900, OBATA Akio wrote: > On Wed, 27 Apr 2011 02:20:51 +0900, Bron Gondwana wrote: > > >On Tue, 26 Apr 2011 10:19 -0700, "David Lang" > > wrote: > >>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? > > > >No, not easily. It would delete the whole tree by default. > > No, "RENAME" will affect to whole tree, but "DELETE" is not. Yes, you're right. Of course, delete is a rename now - but not up at the level where that happens. A lot of clients do convert a delete into a tree delete though (or a rename under Trash in some cases) Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: DECISION: what reconstruct -f should do
On Wed, 27 Apr 2011 02:20:51 +0900, Bron Gondwana wrote: > On Tue, 26 Apr 2011 10:19 -0700, "David Lang" > wrote: >> 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? > > No, not easily. It would delete the whole tree by default. No, "RENAME" will affect to whole tree, but "DELETE" is not. -- OBATA Akio / ob...@lins.jp Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: DECISION: what reconstruct -f should do
Bron Gondwana wrote: > On Tue, 26 Apr 2011 10:19 -0700, "David Lang" > wrote: >> 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? > > No, not easily. It would delete the whole tree by default. Has this changed since Cyrus 2.3? I've certainly created and removed the middle of mailbox paths. How easy or difficult this is may depend on the email client. Mike -- Michael D. Sofka sof...@rpi.edu C&MT Sr. Systems Programmer, Email, HPC, TeX, Epistemology Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: DECISION: what reconstruct -f should do
On Tue, 26 Apr 2011, Bron Gondwana wrote: > On Tue, 26 Apr 2011 10:19 -0700, "David Lang" > wrote: >> 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? > > No, not easily. It would delete the whole tree by default. > >> 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? > > No, that's not a problem. It will create just fine. Ok, in this case your logic makes sense. I would suggest that reconstruct report these cases, so that if the user did want INBOX.sub they have a reminder from the fact that it could have been created, but was not. David Lang Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: DECISION: what reconstruct -f should do
On Tue, 26 Apr 2011 10:19 -0700, "David Lang" wrote: > 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? No, not easily. It would delete the whole tree by default. > 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? No, that's not a problem. It will create just fine. Bron. -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: DECISION: what reconstruct -f should do
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 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
DECISION: what reconstruct -f should do
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. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: POLL: what should reconstruct -f do?
On 2011-04-26 at 07:07, Patrick Boutilier wrote: > Everybody seems to like 3. But if you only have an empty directory with > no message files or something that resembles a cyrus file what is the > point of creating an empty folder? :-) I don't see why we'd suddenly get a spurious empty directory, though it would be added as a new valid empty folder. > Or does 3 assume there are message files in the directory? No, 4 is 3 plus attempting to find valid messages in the directory. -- Øyvind Kolbu Postmaster Universitetet i Oslo Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: POLL: what should reconstruct -f do?
On 04/26/2011 06:52 AM, Øyvind Kolbu wrote: > On 2011-04-23 at 10:34, Jeroen van Meeuwen (Kolab Systems) wrote: >> Bron Gondwana wrote: >>> 3) add the mailbox if there's a directory, don't require >>> cyrus.header. >>> >> >> This one has my preference. > > Mine as well. Everybody seems to like 3. But if you only have an empty directory with no message files or something that resembles a cyrus file what is the point of creating an empty folder? :-) Or does 3 assume there are message files in the directory? > > > > > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: POLL: what should reconstruct -f do?
On 2011-04-23 at 10:34, Jeroen van Meeuwen (Kolab Systems) wrote: > Bron Gondwana wrote: > > 3) add the mailbox if there's a directory, don't require > >cyrus.header. > > > > This one has my preference. Mine as well. -- Øyvind Kolbu Postmaster Universitetet i Oslo pgppS7kNclXEU.pgp Description: PGP signature Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: POLL: what should reconstruct -f do?
> On Saturday 23 April 2011 01:07:00 Bron Gondwana wrote: >> The question came up from the following bug report: >> >> http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3449 >> >> Where there were spool files on disk, but no meta data left. >> Reconstruct gave no information about the files on disk at >> all. >> >> I see 4 options, can I'd like some opinions on what people >> think reconstruct should do. Speak now(ish) or hold your >> peace! >> >> 1) what we do now - require a cyrus.header in the directory >>or ignore it. >> >> 2) like (1) but warn about the directory with no cyrus.header >> >> 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) >> >> >> Alright, cast your votes! I'll come back to this thread in a week >> or so and implement the winner. (4) is the hardest to implement, >> but even that's not very tricky. >> > > I vote for 3. > > Mainly as I am wondering what will happen in the following situation: > A folder "X" exists on the filesystem, but isn't "recorded" as a folder. > > What happens when a user now tries to create folder "X"? > > If the reconstruct had "recorded" it, any possible contents will already > be > known and no further decision about what to do with that folder has to be > made. What I was wondering, isn't it possible with IMAP to have a folder with no parentfolder? If yes, does a reconstruct then create the parent folder which was not intended to be there? Simon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: POLL: what should reconstruct -f do?
On Saturday 23 April 2011 01:07:00 Bron Gondwana wrote: > The question came up from the following bug report: > > http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3449 > > Where there were spool files on disk, but no meta data left. > Reconstruct gave no information about the files on disk at > all. > > I see 4 options, can I'd like some opinions on what people > think reconstruct should do. Speak now(ish) or hold your > peace! > > 1) what we do now - require a cyrus.header in the directory >or ignore it. > > 2) like (1) but warn about the directory with no cyrus.header > > 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) > > > Alright, cast your votes! I'll come back to this thread in a week > or so and implement the winner. (4) is the hardest to implement, > but even that's not very tricky. > I vote for 3. Mainly as I am wondering what will happen in the following situation: A folder "X" exists on the filesystem, but isn't "recorded" as a folder. What happens when a user now tries to create folder "X"? If the reconstruct had "recorded" it, any possible contents will already be known and no further decision about what to do with that folder has to be made. -- Joost Roeleveld Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
