Home : Products : Gossamer Mail : Discussion :

Products: Gossamer Mail: Discussion: consistency.pl and purge.pl inconsistencies: Edit Log

Here is the list of edits for this post
consistency.pl and purge.pl inconsistencies
Hi,

This is just an observation:

purged messages for a user and the count was somewhere around 2500 or so.

regularly purged trash folder.

before doing all this consistency.pl --fix was run to ensure that all is well.

However, ran consistency.pl and found following:

2734 messages were on disk and not in the database

0 messages were in the database but not on disk
validate table inconsistancies: 0
msgtrack table inconsistancies: 0
msgs table inconsistancies: 1
msgs_threads table inconsistancies: 0
msgdata table inconsistancies: 0
msgsearch table inconsistancies: 0
msgs_remote table inconsistancies: 0
pop_accounts table inconsistancies: 0
sigs table inconsistancies: 0
address table inconsistancies: 0
filter table inconsistancies: 0
users => dgraph table inconsistancies: 0
dgraph => users table inconsistancies: 0
sessions table inconsistancies: 0
folders table inconsistancies: 0

Does sit mean that purge from admin is not removing the messages from the disk?

Have run consistency.pl again to synchro everything.

Obviously all the while consistency.pl was being run the site was disabled. Again with everything synchronized, again did a purge messages (Trash 1 Messages Deleted):

consistency.pl gave following result:

2 messages were on disk and not in the database

0 messages were in the database but not on disk
validate table inconsistancies: 0
msgtrack table inconsistancies: 0
msgs table inconsistancies: 0
msgs_threads table inconsistancies: 0
msgdata table inconsistancies: 0
msgsearch table inconsistancies: 0
msgs_remote table inconsistancies: 0
pop_accounts table inconsistancies: 0
sigs table inconsistancies: 0
address table inconsistancies: 0
filter table inconsistancies: 0
users => dgraph table inconsistancies: 0
dgraph => users table inconsistancies: 0
sessions table inconsistancies: 0
folders table inconsistancies: 0

Again did purge messages for a user: 265 messages purged.

Ran consistency.pl and got following:

681 messages were on disk and not in the database

0 messages were in the database but not on disk
validate table inconsistancies: 0
msgtrack table inconsistancies: 0
msgs table inconsistancies: 0
msgs_threads table inconsistancies: 0
msgdata table inconsistancies: 0
msgsearch table inconsistancies: 0
msgs_remote table inconsistancies: 0
pop_accounts table inconsistancies: 0
sigs table inconsistancies: 0
address table inconsistancies: 0
filter table inconsistancies: 0
users => dgraph table inconsistancies: 0
dgraph => users table inconsistancies: 0
sessions table inconsistancies: 0
folders table inconsistancies: 0

So there is some bit of inconsistency between purge and consistency.pl

What could be the reasons?

However, when admin does all the deleting (empty folder) by going to the user account from admin then there are no inconsistencies. So i believe, Purge.pm or something else needs a closer look. It is definitely leading to inconsistencies wrt the mesages on disk and database. For example for a given user when the folder is emptied (85 messages) and also the trash after that, the consistency.pl gives:

0 messages were on disk and not in the database

0 messages were in the database but not on disk
validate table inconsistancies: 0
msgtrack table inconsistancies: 0
msgs table inconsistancies: 0
msgs_threads table inconsistancies: 0
msgdata table inconsistancies: 0
msgsearch table inconsistancies: 0
msgs_remote table inconsistancies: 0
pop_accounts table inconsistancies: 0
sigs table inconsistancies: 0
address table inconsistancies: 0
filter table inconsistancies: 0
users => dgraph table inconsistancies: 0
dgraph => users table inconsistancies: 0
sessions table inconsistancies: 0
folders table inconsistancies: 0

Which is perfectly OK.

It is only the "Purge" operation which is leading to all sorts of inconsistencies.

Any comments.....

Thnx

Anup

Last edited by:

anup123: Mar 14, 2003, 11:10 PM

Edit Log: