Thank you for these informations.
I'm still investigating how to recover from the corrupt GRP error messages we have (they seems to be linked to users having "This message has been removed" in POP and/or IMAP)
1) So about the deleted.cfg it's safe for us to remove them from the users forlders ? I've checked quite a lot of folders and they all have their deleted.cfg file present...
2) Removing the mailbox.cfg to have SM recreate it will then lose the status of the e-mails (replied flag, etc?).
This is quite a problem because we already have cusomters opening support case telling us that replied messages have lost the reply flag, so they have to check the sent items to be sure if they replied or not...
I've ran a little script over our logs to determine which folders are impacted:
grep -hioP '[A-Z]\:\\SmarterMail\\Domains\\.*\\(?=.*\.grp)' 2020*log | sort -u > corrupt.log
The logs shows the moment 252 "unique" folders being affected by this:
$ wc -l corrupt.log
But it seems every day around 10 more unique corrupt folder is detected.
So either the problem is propagating or maybe the new folders are users that haven't accessed their mailbox since we upgraded to latest
beta release, therefore not generating any log entry. I'm not sure what to think here.
About the flags being lost, isn't there a copy of the flags in the GRP files that it can grab when reconstructing mailbox.cfg ? Or is there an utility to clean the mailbox.cfg and fix without losing the flags ?
It's important for us that when attempting to fix these corruptions errors, we do not add problems such as these flags being reset...
ps: We have a ticket open for this issue (1E3-266A74AE-0B0D)