Discussions on the Cyrus IMAP server.

Stephen Ingram | 19 May 2012 18:51

Picon

mailboxes.db vs IMAP client irregularities

I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
an issue with a folder in a mailbox that would not show any
subfolders. I created a new folder 'folder2' and moved all of the
subfolders to it and then performed a reconstruct on the new set of
folders and everything worked. Now I deleted the old folder 'folder'
from the file system and then (after it wouldn't go away from the
cyradm listing) used cyr_dbtool to manually remove it (and the
subfolders) from the mailboxes.db file. The old folders and subfolders
are now gone, however, I can't (using the IMAP client) rename
'folder2' back to 'folder' as when I do, the subfolders are not
visible.

I've dumped the mailboxes.db file to a flat file to look and see if
there is anything in there that wasn't visible in cyradm or using
cyr_dbtool show. Everything is as expected except there are some
DELETED.user.xxx.folder entries at the top. Are you not allowed the
create folders with the same name you've just deleted? Where are these
DELETED folders actually stored and how long does it take them to go
away? (I'm not using delayed expunge.)

If that's not the issue, then is there some other file besides
mailboxes.db that might contain bad information or is this a bug in
the system?

Steve
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

(Continue reading)

Patrick Boutilier | 19 May 2012 19:58

Picon

Re: mailboxes.db vs IMAP client irregularities

On 05/19/2012 01:51 PM, Stephen Ingram wrote:
> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
> an issue with a folder in a mailbox that would not show any
> subfolders. I created a new folder 'folder2' and moved all of the
> subfolders to it and then performed a reconstruct on the new set of
> folders and everything worked. Now I deleted the old folder 'folder'
> from the file system and then (after it wouldn't go away from the
> cyradm listing) used cyr_dbtool to manually remove it (and the
> subfolders) from the mailboxes.db file. The old folders and subfolders
> are now gone, however, I can't (using the IMAP client) rename
> 'folder2' back to 'folder' as when I do, the subfolders are not
> visible.
>
> I've dumped the mailboxes.db file to a flat file to look and see if
> there is anything in there that wasn't visible in cyradm or using
> cyr_dbtool show. Everything is as expected except there are some
> DELETED.user.xxx.folder entries at the top. Are you not allowed the
> create folders with the same name you've just deleted? Where are these
> DELETED folders actually stored and how long does it take them to go
> away? (I'm not using delayed expunge.)

Sounds like you are using delayed delete. Mine show up in 
/imap/mail/C/DELETED/  . How long they stay around depends on when you 
run cyr_expire and what parameters you give it.

Man page entries:

deletedprefix: DELETED
             If  "delete_mode"  set  to  be  "delayed",  the  prefix for 
the deleted mailboxes hierarchy.  The hierarchy delimiter will be

(Continue reading)

Stephen Ingram | 19 May 2012 21:02

Picon

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 10:58 AM, Patrick Boutilier
<boutilpj <at> ednet.ns.ca> wrote:
> On 05/19/2012 01:51 PM, Stephen Ingram wrote:
>>
>> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
>> an issue with a folder in a mailbox that would not show any
>> subfolders. I created a new folder 'folder2' and moved all of the
>> subfolders to it and then performed a reconstruct on the new set of
>> folders and everything worked. Now I deleted the old folder 'folder'
>> from the file system and then (after it wouldn't go away from the
>> cyradm listing) used cyr_dbtool to manually remove it (and the
>> subfolders) from the mailboxes.db file. The old folders and subfolders
>> are now gone, however, I can't (using the IMAP client) rename
>> 'folder2' back to 'folder' as when I do, the subfolders are not
>> visible.
>>
>> I've dumped the mailboxes.db file to a flat file to look and see if
>> there is anything in there that wasn't visible in cyradm or using
>> cyr_dbtool show. Everything is as expected except there are some
>> DELETED.user.xxx.folder entries at the top. Are you not allowed the
>> create folders with the same name you've just deleted? Where are these
>> DELETED folders actually stored and how long does it take them to go
>> away? (I'm not using delayed expunge.)
>
>
> Sounds like you are using delayed delete. Mine show up in
> /imap/mail/C/DELETED/  . How long they stay around depends on when you run
> cyr_expire and what parameters you give it.
>
>

(Continue reading)

Patrick Boutilier | 19 May 2012 21:40

Picon

Re: mailboxes.db vs IMAP client irregularities

On 05/19/2012 04:02 PM, Stephen Ingram wrote:
> On Sat, May 19, 2012 at 10:58 AM, Patrick Boutilier
> <boutilpj <at> ednet.ns.ca>  wrote:
>> On 05/19/2012 01:51 PM, Stephen Ingram wrote:
>>>
>>> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
>>> an issue with a folder in a mailbox that would not show any
>>> subfolders. I created a new folder 'folder2' and moved all of the
>>> subfolders to it and then performed a reconstruct on the new set of
>>> folders and everything worked. Now I deleted the old folder 'folder'
>>> from the file system and then (after it wouldn't go away from the
>>> cyradm listing) used cyr_dbtool to manually remove it (and the
>>> subfolders) from the mailboxes.db file. The old folders and subfolders
>>> are now gone, however, I can't (using the IMAP client) rename
>>> 'folder2' back to 'folder' as when I do, the subfolders are not
>>> visible.
>>>
>>> I've dumped the mailboxes.db file to a flat file to look and see if
>>> there is anything in there that wasn't visible in cyradm or using
>>> cyr_dbtool show. Everything is as expected except there are some
>>> DELETED.user.xxx.folder entries at the top. Are you not allowed the
>>> create folders with the same name you've just deleted? Where are these
>>> DELETED folders actually stored and how long does it take them to go
>>> away? (I'm not using delayed expunge.)
>>
>>
>> Sounds like you are using delayed delete. Mine show up in
>> /imap/mail/C/DELETED/  . How long they stay around depends on when you run
>> cyr_expire and what parameters you give it.
>>

(Continue reading)

Stephen Ingram | 19 May 2012 21:56

Picon

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 12:40 PM, Patrick Boutilier
<boutilpj <at> ednet.ns.ca> wrote:
> On 05/19/2012 04:02 PM, Stephen Ingram wrote:
>>
>> On Sat, May 19, 2012 at 10:58 AM, Patrick Boutilier
>> <boutilpj <at> ednet.ns.ca>  wrote:
>>>
>>> On 05/19/2012 01:51 PM, Stephen Ingram wrote:
>>>>
>>>>
>>>> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
>>>> an issue with a folder in a mailbox that would not show any
>>>> subfolders. I created a new folder 'folder2' and moved all of the
>>>> subfolders to it and then performed a reconstruct on the new set of
>>>> folders and everything worked. Now I deleted the old folder 'folder'
>>>> from the file system and then (after it wouldn't go away from the
>>>> cyradm listing) used cyr_dbtool to manually remove it (and the
>>>> subfolders) from the mailboxes.db file. The old folders and subfolders
>>>> are now gone, however, I can't (using the IMAP client) rename
>>>> 'folder2' back to 'folder' as when I do, the subfolders are not
>>>> visible.
>>>>
>>>> I've dumped the mailboxes.db file to a flat file to look and see if
>>>> there is anything in there that wasn't visible in cyradm or using
>>>> cyr_dbtool show. Everything is as expected except there are some
>>>> DELETED.user.xxx.folder entries at the top. Are you not allowed the
>>>> create folders with the same name you've just deleted? Where are these
>>>> DELETED folders actually stored and how long does it take them to go
>>>> away? (I'm not using delayed expunge.)
>>>

(Continue reading)

Bron Gondwana | 19 May 2012 22:28

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 12:56:44PM -0700, Stephen Ingram wrote:
> Wow, thanks! I didn't know about that command. It exposed them!
> Strange, they were in /var/spool/imap/u/DELETED/ (my mailbox root is
> /var/spool/imap). I'm not sure why they wouldn't be in
> /var/spool/imap/j/user/jmaxwell (jmaxwell is the user), but perhaps
> it's because I haven't defined deleted_prefix as you pointed out
> earlier. Maybe /var/spool/imap/u/DELETED is the default.

Hashing is on the second part of the name, rather uninteligently,
no matter what the name - hence it's hashing on:

DELETE.user.x
       ^

:)

> Looking at all of the files in there, several are older than the 3
> days they are supposed to be. I'm guessing that means there was a bug
> somewhere. I guess I should remove all of these, reconstruct the
> mailboxes.db to match and then probably upgrade as Bron suggested.

No - the files will have the delivery date as their age.  The interesting
bit is the final part of the folder name, which is actually a 32 bit
unix timestamp in hex format (yes, really).

cyr_expire will clean it up.  Don't mess with the filesystem under cyrus
if you don't have to.

Bron.
----

(Continue reading)

Stephen Ingram | 19 May 2012 23:02

Picon

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 1:28 PM, Bron Gondwana <brong <at> fastmail.fm> wrote:
> On Sat, May 19, 2012 at 12:56:44PM -0700, Stephen Ingram wrote:
>> Wow, thanks! I didn't know about that command. It exposed them!
>> Strange, they were in /var/spool/imap/u/DELETED/ (my mailbox root is
>> /var/spool/imap). I'm not sure why they wouldn't be in
>> /var/spool/imap/j/user/jmaxwell (jmaxwell is the user), but perhaps
>> it's because I haven't defined deleted_prefix as you pointed out
>> earlier. Maybe /var/spool/imap/u/DELETED is the default.
>
> Hashing is on the second part of the name, rather uninteligently,
> no matter what the name - hence it's hashing on:
>
> DELETE.user.x
>       ^
>
> :)
>
>> Looking at all of the files in there, several are older than the 3
>> days they are supposed to be. I'm guessing that means there was a bug
>> somewhere. I guess I should remove all of these, reconstruct the
>> mailboxes.db to match and then probably upgrade as Bron suggested.
>
> No - the files will have the delivery date as their age.  The interesting
> bit is the final part of the folder name, which is actually a 32 bit
> unix timestamp in hex format (yes, really).

Wow, I never stopped being amazed by the really clever hidden things
in cyrus-imap!

> cyr_expire will clean it up.  Don't mess with the filesystem under cyrus

(Continue reading)

Bron Gondwana | 19 May 2012 23:05

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 02:02:53PM -0700, Stephen Ingram wrote:
> BTW, I love 2.4. I've been using now for several months and it is such
> a HUGE improvement from 2.3. Everything is faster, replication works
> better, it's like a whole new program!

Just wait until you get 2.5 :)  There's still lots left to do, but
it's coming along.  I really want to get more of the last years'
worth of development out to people too!

Bron
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Simon Matter | 19 May 2012 22:00

Picon

Re: mailboxes.db vs IMAP client irregularities

> On 05/19/2012 01:51 PM, Stephen Ingram wrote:
>> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
>> an issue with a folder in a mailbox that would not show any
>> subfolders. I created a new folder 'folder2' and moved all of the
>> subfolders to it and then performed a reconstruct on the new set of
>> folders and everything worked. Now I deleted the old folder 'folder'
>> from the file system and then (after it wouldn't go away from the
>> cyradm listing) used cyr_dbtool to manually remove it (and the
>> subfolders) from the mailboxes.db file. The old folders and subfolders
>> are now gone, however, I can't (using the IMAP client) rename
>> 'folder2' back to 'folder' as when I do, the subfolders are not
>> visible.
>>
>> I've dumped the mailboxes.db file to a flat file to look and see if
>> there is anything in there that wasn't visible in cyradm or using
>> cyr_dbtool show. Everything is as expected except there are some
>> DELETED.user.xxx.folder entries at the top. Are you not allowed the
>> create folders with the same name you've just deleted? Where are these
>> DELETED folders actually stored and how long does it take them to go
>> away? (I'm not using delayed expunge.)
>
> Sounds like you are using delayed delete. Mine show up in
> /imap/mail/C/DELETED/  . How long they stay around depends on when you
> run cyr_expire and what parameters you give it.
>
>
> Man page entries:
>
> deletedprefix: DELETED
>              If  "delete_mode"  set  to  be  "delayed",  the  prefix for

(Continue reading)

Stephen Ingram | 19 May 2012 22:50

Picon

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 1:00 PM, Simon Matter <simon.matter <at> invoca.ch> wrote:
>> On 05/19/2012 01:51 PM, Stephen Ingram wrote:
>>> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
>>> an issue with a folder in a mailbox that would not show any
>>> subfolders. I created a new folder 'folder2' and moved all of the
>>> subfolders to it and then performed a reconstruct on the new set of
>>> folders and everything worked. Now I deleted the old folder 'folder'
>>> from the file system and then (after it wouldn't go away from the
>>> cyradm listing) used cyr_dbtool to manually remove it (and the
>>> subfolders) from the mailboxes.db file. The old folders and subfolders
>>> are now gone, however, I can't (using the IMAP client) rename
>>> 'folder2' back to 'folder' as when I do, the subfolders are not
>>> visible.
>>>
>>> I've dumped the mailboxes.db file to a flat file to look and see if
>>> there is anything in there that wasn't visible in cyradm or using
>>> cyr_dbtool show. Everything is as expected except there are some
>>> DELETED.user.xxx.folder entries at the top. Are you not allowed the
>>> create folders with the same name you've just deleted? Where are these
>>> DELETED folders actually stored and how long does it take them to go
>>> away? (I'm not using delayed expunge.)
>>
>> Sounds like you are using delayed delete. Mine show up in
>> /imap/mail/C/DELETED/  . How long they stay around depends on when you
>> run cyr_expire and what parameters you give it.
>>
>>
>> Man page entries:
>>
>> deletedprefix: DELETED

(Continue reading)

Bron Gondwana | 19 May 2012 19:59

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 09:51:38AM -0700, Stephen Ingram wrote:
> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had

Could be sort order bugs with 2.4.13 if you don't have
improved_mboxlist_sort turned on.

> I've dumped the mailboxes.db file to a flat file to look and see if
> there is anything in there that wasn't visible in cyradm or using
> cyr_dbtool show. Everything is as expected except there are some
> DELETED.user.xxx.folder entries at the top. Are you not allowed the
> create folders with the same name you've just deleted? Where are these
> DELETED folders actually stored and how long does it take them to go
> away? (I'm not using delayed expunge.)

Do you have folder names like:

user.xxx
user.xxx.fol der
user.xxx.fol.stuff

rather than:

user.xxx
user.xxx.fol.stuff
user.xxx.fol der

A fix is to upgrade to a new version of 2.4.x.

Bron.
----

(Continue reading)

Stephen Ingram | 19 May 2012 20:53

Picon

Re: mailboxes.db vs IMAP client irregularities

On Sat, May 19, 2012 at 10:59 AM, Bron Gondwana <brong <at> fastmail.fm> wrote:
> On Sat, May 19, 2012 at 09:51:38AM -0700, Stephen Ingram wrote:
>> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
>
> Could be sort order bugs with 2.4.13 if you don't have
> improved_mboxlist_sort turned on.
>
>> I've dumped the mailboxes.db file to a flat file to look and see if
>> there is anything in there that wasn't visible in cyradm or using
>> cyr_dbtool show. Everything is as expected except there are some
>> DELETED.user.xxx.folder entries at the top. Are you not allowed the
>> create folders with the same name you've just deleted? Where are these
>> DELETED folders actually stored and how long does it take them to go
>> away? (I'm not using delayed expunge.)
>
> Do you have folder names like:
>
> user.xxx
> user.xxx.fol der
> user.xxx.fol.stuff
>
> rather than:
>
> user.xxx
> user.xxx.fol.stuff
> user.xxx.fol der
>
> A fix is to upgrade to a new version of 2.4.x.

Are you saying that the sort order could be wrong or that the

(Continue reading)

Bron Gondwana | 19 May 2012 22:04

Re: mailboxes.db vs IMAP client irregularities


On Sat, May 19, 2012, at 11:53 AM, Stephen Ingram wrote:
> On Sat, May 19, 2012 at 10:59 AM, Bron Gondwana <brong <at> fastmail.fm> wrote:
> > On Sat, May 19, 2012 at 09:51:38AM -0700, Stephen Ingram wrote:
> >> I'm running 2.4.13 from the invoca rpms on CentOS 5.8. I recently had
> >
> > Could be sort order bugs with 2.4.13 if you don't have
> > improved_mboxlist_sort turned on.
> >
> >> I've dumped the mailboxes.db file to a flat file to look and see if
> >> there is anything in there that wasn't visible in cyradm or using
> >> cyr_dbtool show. Everything is as expected except there are some
> >> DELETED.user.xxx.folder entries at the top. Are you not allowed the
> >> create folders with the same name you've just deleted? Where are these
> >> DELETED folders actually stored and how long does it take them to go
> >> away? (I'm not using delayed expunge.)
> >
> > Do you have folder names like:
> >
> > user.xxx
> > user.xxx.fol der
> > user.xxx.fol.stuff
> >
> > rather than:
> >
> > user.xxx
> > user.xxx.fol.stuff
> > user.xxx.fol der
> >
> > A fix is to upgrade to a new version of 2.4.x.

(Continue reading)

Return

Return to gmane.mail.imap.cyrus.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane