On Thu, 24 Mar 2022, at 5:22 AM, Andy Dorman wrote: > Are we pretty sure that manually creating a new username mailbox in uuid > storage then copying the mail subdirectories and files from the old > mailbox storage directory, > /var/spool/cyrus/mail/domain/B/domain.com/S/user/username/*, to the new, > /var/spool/cyrus/mail/uuid/o/k/okw.../, and then trying reconstruct > would be a disaster? Maybe not disaster necessarily, but it wouldn't _work_ (more below). Buuuuuut, what might work is something like: * First, manually create the user's full hierarchy in uuid storage (using cyradm or similar), like: createmailbox user/foo createmailbox user/foo/Drafts createmailbox user/foo/Trash createmailbox user/foo/Sent createmailbox user/foo/whatever createmailbox user/foo/whatever/else and so on. I assume you know better than I how to do this; please take these instructions as "the general idea", not "specific commands to copy and paste". * Now, on the filesystem, you'll have a bunch of new .../uuid/././.../ directories, one for each of those mailboxes you just created. mbpath will be able to tell you which is which. * Then (carefully) copy the files from each old mailbox storage directory to its corresponding new uuid one * Finally, a recursive reconstruct of the user should then find everything? I think you won't need -f this time, since the mailboxes already exist, we're just rediscovering their contents. > If the new uuid storage change is just to have a nice, clean, unique > uuid to use for the username directory but the underlying mailbox > headers, indexes and such are the same, then that might work don't you > think? If that were the case, then it might work, but it's not, so it won't. :) Under the new uuid storage, _every mailbox is stored by its uuid_. The mailbox hierarchy is not reflected in the filesystem hierarchy at all. (The new cyr_cd.sh and cyr_ls tools, as well as the existing mbpath tool, allow you to still find your way around on the filesystem if you need to.) This greatly improves performance and safety when users with multiple gigabytes of mail decide they want to rename a big mailbox or reorganise their filing -- since now all that happens is a name change in mailboxes.db, and not a massive filesystem shuffle. It also makes renaming entire accounts cheap and more atomic, instead of expensive and precarious. > We really appreciate all your help with this. No worries, I really appreciate you trying out the beta, so we can get these kinks ironed out before release! I believe all this mess descends from the original segfault, so it'd be really nice to get to the bottom of that. I imagine the segfault was due to some edge case mailboxes in your environment that we don't handle properly but haven't yet stumbled across ourselves. Once this mess is cleaned up and your users can use their mail again, if you were able to reproduce the crash in a test environment and get a core dump, that would be tremendously helpful. (Perhaps by setting up a vm with 3.4, configuring it to save core dumps, restoring data from a pre-upgrade backup into it so it has the same mailboxes as one of the systems that crashed during upgrade, and then upgrading to 3.6 and hopefully reproducing the crash, with a core.) If you manage to reproduce the crash and get a core file from it, let us know, and we can provide instructions on how to examine it and what we need to see from it. Cheers, ellie ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/T9d294f89a3d1d260-M4076109ec57051e502acb0f7 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
