omcontain : [OM 3457] Container is an old version

[tbarber]

We have been able to recover most of our messages and folders with the omcontain tool however on some of the folders we receive
"[OM 3457] Container is an old version and needs to be upgraded" or also "[OM 3541] Content Record has not been upgraded to current container format."
When trying to open the folder. Anyone know how I might upgrade a folder?

I'm running scalix 11.0.0 beta on SUSE 10.1 beta, but the original server ran Scalix 9.4.0 and SuSE 9.3.
we upgraded due to problems with recovery on 9.4 due to a problem belived to be related to this bugzilla link. http://bugzilla.scalix.com/show_bug.cgi?id=12624
and this scalix forum link. http://www.scalix.com/community/viewtop ... r&start=15

any help greatly appreciated.
BTW Thank you florian!

[kjordan]

I'm having the same problem, does anyone have a fix?

[tonyn]

I'm running scalix 11.0.0 beta on SUSE 10.1 beta, but the original server ran Scalix 9.4.0 and SuSE 9.3.
we upgraded due to problems with recovery on 9.4 due to a problem belived to be related to this bugzilla link.

So to be clear, were these remaining problem folders, exhibiting the same problems (i.e OM 3457 and OM 3541 errors) BEFORE you upgraded to Scalix 11? If so, the bug and forum thread you mention are, as you suggest, the most likely reason. But if you only started seeing the errors after upgrading to the Scalix 11 Beta, I would be interested in the output from omshowlog around the time when you try and open the folder container using omcontain, just in case there is a new problem that needs investigation.

Either way, I suspect all you can do at this stage is delete the offending messages which are causing the folder container upgrade from completing. With Scalix 11 (this option was NOT available in earlier versions) you can run omcontain with the new "-f" option i.e: "omcontain -f".
Then as you perform the usual omcontain commands to descend down and open the offending folder, it will zap any content records which it fails to upgrade. This will result in some orphan files (for the messages which are no longer attached to a parent folder), which omscan will report and optionally remove for you, the next time you run it.

[tbarber]

I'm running scalix 11.0.0 beta on SUSE 10.1 beta, but the original server ran Scalix 9.4.0 and SuSE 9.3.
we upgraded due to problems with recovery on 9.4 due to a problem belived to be related to this bugzilla link.

So to be clear, were these remaining problem folders, exhibiting the same problems (i.e OM 3457 and OM 3541 errors) BEFORE you upgraded to Scalix 11? If so, the bug and forum thread you mention are, as you suggest, the most likely reason. But if you only started seeing the errors after upgrading to the Scalix 11 Beta, I would be interested in the output from omshowlog around the time when you try and open the folder container using omcontain, just in case there is a new problem that needs investigation.

Either way, I suspect all you can do at this stage is delete the offending messages which are causing the folder container upgrade from completing. With Scalix 11 (this option was NOT available in earlier versions) you can run omcontain with the new "-f" option i.e: "omcontain -f".
Then as you perform the usual omcontain commands to descend down and open the offending folder, it will zap any content records which it fails to upgrade. This will result in some orphan files (for the messages which are no longer attached to a parent folder), which omscan will report and optionally remove for you, the next time you run it.

That worked for the most part, but I'm getting a load of "[OM 28881] Bad magic number in a serialised file." and "[OM 28879] Bad magic number in an item index record." errors/warnings. How can I just clear out every message with these? I could potentially have to do this on dozens and when I do an omtidyu, it shows that for some that aren't even having that error when I delete them.

Is there a way to mass move messages without having to move the container they're in? I'd like to move all the messages to the inbox and then just download them through pop3 to get them off but I don't see any command that does that.

[tonyn]

That worked for the most part, but I'm getting a load of "[OM 28881] Bad magic number in a serialised file." and "[OM 28879] Bad magic number in an item index record." errors/warnings. How can I just clear out every message with these?

Have you run omscan? I would have thought that it would report all these file corruptions in the message store (possibly indirectly as - "missing children"). Then running omscan in fix mode should delete the references to those missing children.

Personally though, I would try and track down each error that omscan reports, using omcontain, and satisfy myself that I am happy to lose that message/folder/item before running omscan in fix mode. I find the omcontain "O" (upper case letter) command, which opens the parent container of an item directly, particularly useful in tracking down any bad items that omscan reports.

[tbarber]

In answer to the previous post

1.
So to be clear, were these remaining problem folders, exhibiting the same problems (i.e OM 3457 and OM 3541 errors) BEFORE you upgraded to Scalix 11? : yes same problem.

2.
I would be interested in the output from omshowlog around the time when you try and open the folder container using omcontain, just in case there is a new problem that needs investigation. : I would be more than happy to email you the log file. Posting it is not an option as it is 233589 lines and contains personal information on my users.

3. omcontain -f "O" Is an option I have been able to open a file and attach it to another directory. However the omshowlog shows that the file has a bad magic number. Yet i'm still able to open it move it delete it ect...

For example this is the a piece of the log on a file that I opened with omcontain -f "O"

WARNING Local Client I(U/I Access ) 10.19.06 11:51:47
[OM 28879] Bad magic number in an item index record.
User Name: user/ scalix, domain/CN=user
Last Msg Subject: Re: Linda's address
Last Msg Sender: user///scalix/domaine//////////////////%user%%%//"user
Last Msg Id: 440474F2.3060800(a)
Last Msg DirectRef: 000364d29e170efa
Last Folder: Sent
Last Ct RecNo: 669
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1697[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1394[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1697[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1394[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1697[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1394[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1697[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1394[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1697[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1394[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1697[100,28875]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_io.c:235[100,28879]
<- /build/11.0.0.196-beta/src/lib/ombase/sfl/sfl_Blcked.c:1697[100,28879]
<- /build/11.0.0.196-beta/src/lib/ct/ct_readc.c:275[100,28879]
<- /build/11.0.0.196-beta/src/lib/ct/ct_fndnxt.c:81[100,28879]
<- /build/11.0.0.196-beta/src/lib/ct/ct_readc.c:158[100,28879]

[tbarber]

In reply to:

Have you run omscan? I would have thought that it would report all these file corruptions in the message store (possibly indirectly as - "missing children"). Then running omscan in fix mode should delete the references to those missing children.

I have my data backed up on mulitple drives with dd and have been able to experiment with both 9.4 and 11.0.0 using the omscan options. omscan -Aafx on 9.4 dumped approx 11gb 90% of the data orphaned dir. On 11.0.0 omscan -Aafx left the data in the data dir and did not create an orphaned dir. I thought that was interesting.

[tbarber]

This is just a note for administrators running scalix or looking into it.

Set up ISDB !!!!!! If the administrator that set up this server would have looked into a recovery process. I could have made a full recovery smoothly. If you do not set up ISDB your only other option is to recover your users mail 1 piece at a time if a container is broken. That could take the most part of a year even on a small network.

[tonyn]

[quote:this post will be deleted]1.
So to be clear, were these remaining problem folders, exhibiting the same problems (i.e OM 3457 and OM 3541 errors) BEFORE you upgraded to Scalix 11? : yes same problem.
[/quote:this post will be deleted]

In that case, as it's an old problem, I don't need the omshowlog output - thanks.

[quote:this post will be deleted]3. omcontain -f "O" Is an option I have been able to open a file and attach it to another directory. However the omshowlog shows that the file has a bad magic number. Yet i'm still able to open it move it delete it ect... [/quote:this post will be deleted]

First, please don't _routinely_ use the "-f" option to omcontain. It is only a last-resort fix option if you are getting the OM 3457 and/or OM 3541 errors specifically. Better to see those errors first, with a normal run of omcontain, and then fix them consciously with a second run of omcontain with "-f", later.

Now as far as the "Bad Magic Number" error is concerned, I assume that if you delete the message container using omcontain ("d" option), rather than a mail client, - then you no longer get the error?

[tbarber]

1.
So to be clear, were these remaining problem folders, exhibiting the same problems (i.e OM 3457 and OM 3541 errors) BEFORE you upgraded to Scalix 11? : yes same problem.

In that case, as it's an old problem, I don't need the omshowlog output - thanks.

3. omcontain -f "O" Is an option I have been able to open a file and attach it to another directory. However the omshowlog shows that the file has a bad magic number. Yet i'm still able to open it move it delete it ect...

First, please don't _routinely_ use the "-f" option to omcontain. It is only a last-resort fix option if you are getting the OM 3457 and/or OM 3541 errors specifically. Better to see those errors first, with a normal run of omcontain, and then fix them consciously with a second run of omcontain with "-f", later.

Now as far as the "Bad Magic Number" error is concerned, I assume that if you delete the message container using omcontain ("d" option), rather than a mail client, - then you no longer get the error?

Yes, that's correct. If we delete it with the d option it gets rid of it. Problem is figuring out which ones have that problem. We could have many dozens that could have the "Bad Magic Number Error" and even omshowlog isn't much help since it only shows a few (and even some which don't have that problem, at least using "d" in omcontain shows no errors when it deletes them).

[tonyn]

And omscan on your scalix-11 system, in report mode (not fix mode) does not report any errors (apart from orphans) ?

[tbarber]

That isn't the case when we run omscan -Aafx on scalix 11.0.0 omscan reports alot of bad magic number errors but it does not create a orphans dir or dump the files anywhere the scan just leaves them in the data dir.