> Does anybody have a detailed desciption of the binary setup of the *.PMI and *.PMM files for this file ?

This is an old description but it's valid except for some flags that are not material to your problem.  Over 90% of the time this reindexing problem is caused by something else accessing the mailbox files when Pegasus Mail is trying to write to a file. The first things that come to mind are multiple access to a single mailbox and anti-virus software doing on-open checking.

Folders:

A Pegasus Mail 2.2 folder consists of two files. The master file has the extension .PMM: it has a 128-byte header of which the first 50 bytes are the long name of the folder, the remainder being reserved. Following the header is the text of all the messages in the folder, separated by ^Z characters (ASCII 26). Some of the messages stored in the folder may in fact be deleted  there is no way of determining this without consulting the record matching the message in the .PMI index file for the folder.

The other file has the extension .PMI, and consists of a
representation of the message using a structure called an IMESSAGE, shown below in its C language definition (note that all integer values in the file are stored in Intel word order  Pegasus Mail for the Macintosh does whatever conversion is necessary for its Motorola processor as it loads each entry from the index):

typedef struct
{
unsigned long flags;
unsigned long fpos; /* Offset in master file */
WORD msg_number; /* Msg ordinal position */
char fname; /* Unused in folders */
char from [30]; /* Sender of message */
char subject [36]; /* Guess what this is */
char date [20]; /* Reduced form of date */
long mtime; /* See below */
long fsize; /* Bytes in this message */
} IMESSAGE;

flags is a bitmap of message characteristics, using the following values:

0x1 The message has Pegasus Mail-style attachments
0x2 The message is a uuencoded file transmission
0x4 The message is encrypted
0x80 The message has been read
0x2000 Sender requests confirmation of reading
0x20000L The message is a copy to self
0x40000L The message has been deleted
0x80000L The message is in a MIME transmission format
0x100000L A reply has been sent for this message
0x200000L The message has been forwarded to another user
0x400000L The message is urgent (never seen in folders)
0x800000L The message contains BinHex-encoded enclosures
0x1000000L The message originates from an MHS system
0x2000000L The message originates from an SMTP system.
0x4000000L The message has annotations.
0x8000000L The message contains enclosures

All other values are reserved - do not use them.

The mtime field is a crude calculation of the number of seconds since Jan 1 1990, used only for sorting purposes. It is not intended to be accurate merely "near enough".

The fsize field can be larger than the actual size of the message, but in no circumstance should it be less - this will cause Pegasus Mail to crash.

I have asked this question in a previous thread together with some crash issues. Since Michael solved the crash issues, I would like to open a new thread just for this.

Problem: When closing pegasus, ca. once a week I receive an error message, that the folder for outgoing mail copies needs to be reindexed, which leads to all kinds of trouble, like mails having been sorted into other folders reoccure, mails get lost, etc.

Error Message:.Datenfehler im Ordner entdeckt .... **vermutlich ungültiger Offset im Indexeintrag

After reindexing the folder, everything is op for some days.

It only happens with this folder.

I would like to know how to find out what exacly is the the problem. Whih measn testing the integrity of the index file in details.

Does anyone have the same problem ?

Does anybody have a detailed desciption of the binary setup of the *.PMI and *.PMM files for this file ?

Thanks, Eric

[quote user="EricEffern"]I would like to know how to find out what exacly is the the problem. [/quote]

It won't help in figuring out what causes this, but you may be able to solve this issue by creating a new folder, copying all existing messages to it, then delete the original folder and finally rename the new one. You may have to adjust your filter rules after doing so, though, if this folder is the target folder of any filtering rules.