I've not seen that issue in association with the resetting font message, Brian. Offset index problems occur amongst our staff about once a month over c.75 mail accounts (that's just once a month, not once per account per month). I usually manually fix it by backing up, then copying mail to new folder. I rarely re-index because it just brings back deleted messages - a problem when some of our staff have nearly 20GB of mail [^o)]

Hi

We have recently installed Win7 client PC's to replace our aging XP stock in a Windows Active Directory environment.

Each client uses Pegasus Mail via a shortcut to a central installation on a Windows 2008 Storage Server. All the mail accounts are stored on the same server. Generally, this has worked fine for many years but we have one account where the settings are repeatedly being reset since the account owner moved from XP to Win7, most recently today.

The signatures will go - I mean they are not present at all and need to be entered again and the settings adjusted so that the signatures appear on new mail. The 'tell tale window' settings need to be redone. The option to hide the taskbar entry has to be unchecked. Sometimes a font reset message appears when the account is accessed stating that Pegasus Mail had to reset the font selections.

I take daily incremental backups and have compared the signature files (.pns and .pms) from yesterday and today but both are same same size/date, which seems paradoxical, unless the settings were removed yesterday which is highly unlikely.

The person who uses this account has full control over the folder that contains the mail data.

Anyone know what might be causing this, please?

Thanks! 

[edit]

Also - options for deleted items folder, spell check and copies to self are being reset

It sounds like something is interfering with Pegasus Mail being able to update its configuration files during shutdown.  You have confirmed that it is not a permissions issue so I would check to insure there is no active AV scanning of that mailbox directory and would ask the user whether they are closing Pegasus Mail before shutting down the PC.

Also, if you have space quotas set for the users check to make sure this user is ok.  I have seen strange behavior in Peg when users hit their quota, usually in the form of folder index issues though.

BTW, your setup is the same as mine.  Peg shared from a Server2008 machine.  Mailboxes on same.  I am running v4.63.

Hi, Brian

Thanks a lot for your reply.

I do have quota management enabled but this is purely passive. I use it simply to keep track of heavy users who are likely to hit the 2GB limit for files.

AV is active. The scanner is activated on Read, not Write so nothing should be intefering with the saving of configuration files. It's a pretty fast server with RAID 5 array for the data drives and RAID 1 for the OS drives, 64bit, 50% disk space free etc. We occasionally use some hefty files but because our network is quite small, 100Mb wired and all on one subnet we do not have slow network/access issues.

I have spoken to the person who uses the account and she has said that she religiously closes all applications (Pegasus Mail, databases, MS-Office apps) before shutting down her computer. However, the issue happened again today when she started Pegasus Mail this morning. But, it is worth noting that her computer has not been turned off for two days. So, yesterday morning the options were reset when Pegasus Mail was started, she closed Pegasus Mail when she left the office yesterday afternoon but the computer was left on overnight and this morning when starting Pegasus Mail the options had been reset again.

We are also running V 4.63 Build 325

I am reluctant to disable AV scanning of the Pegasus Mail folder because I occasionally use Pegasus Mail when logged onto the server to troubleshoot mail/folder issues and do not want to run the risk of infecting it.

If you want your AV to scan the Newmail directory, I would suggest you use the Virscan extension (see Downloads area at this site) to invoke your AV rather than having realtime scanning active on this directory. There have been many reports of Folder corruptions which seem to be following AV interference while Pegasus MNail is updating the index files. There are no executable files in the Newmail directory that can cause infections of your machine.

Martin 

I don't believe leaving the computer on would cause the problem.  I doesn't on mine which I on restart about once a week for a 'refresh'.  I am still suspicious of AV interference but it do not know why it would cause a problem for only a single user.

[quote user="irelam"]

If you want your AV to scan the Newmail directory, I would suggest you use the Virscan extension (see Downloads area at this site) to invoke your AV rather than having realtime scanning active on this directory. There have been many reports of Folder corruptions which seem to be following AV interference while Pegasus MNail is updating the index files. There are no executable files in the Newmail directory that can cause infections of your machine.

Martin 

[/quote]

Thanks. However, the scanner is only active on Read, not on write. Our folder structure is setup as follows: There is a folder off the root of the drive named Pmail. Pmail contains the Pegasus Mail program files. User mail folders are located off Pmail. Thus D:\Pmail\Jimbo contains all of Jimbo's email.

Each client has AV installed so attachments are scanned when accessed.

There is nothing interfering when files are being written to the Pmail subfolders.

I agree, it is very odd. I do not understand why just one user's mail account is experiencing this problem. The machine is a brand new computer and is identical to 14 others that have been installed during the last few weeks. 

AFAIK, all of the problems you mentioned have their settings stored in the PMAIL.INI file.  If you have ruled out anything interfering with the updating of this file then I suggest rebuilding it.  No guarantees that is will solve the problem but it is relatively easy to do (unless there are a lot of identities) and doing so has solved odd problems for me in the past. 

For anyone reading this who is not familiar with the PMAIL.INI, rebuilding it should not be required and is not recommended.  I consider rebuilding it to be a last resort at resolving issues associated with configuration.  A PMAIL.INI file is located in each mailbox directory and is specific to that particular user (mailbox).  To rebuild it you first make sure that mailbox is not in use by Pegasus Mail (existence of a file named MAILBOXP.LCK indicates that the mailbox is in use but does not exist in all cases so may not be relied on as the only indicator).  You then rename PMAIL.INI to something like PMAIL_INI.BAD.  When Peg next starts for that user it will prompt for configuration.  Configure all settings as if doing a new install (no need to recreate POP3 and SMTP hosts).  Once done, close Pegasus Mail.  It will have created a new PMAIL.INI file and will write the configuration settings to it as part of its shutdown process. 

Hint:  A printout of the old PMAIL.INI file can be valuable as a reference during configuration.

[quote user="bfluet"]

AFAIK, all of the problems you mentioned have their settings stored in the PMAIL.INI file.  If you have ruled out anything interfering with the updating of this file then I suggest rebuilding it.  No guarantees that is will solve the problem but it is relatively easy to do (unless there are a lot of identities) and doing so has solved odd problems for me in the past. 

For anyone reading this who is not familiar with the PMAIL.INI, rebuilding it should not be required and is not recommended.  I consider rebuilding it to be a last resort at resolving issues associated with configuration.  A PMAIL.INI file is located in each mailbox directory and is specific to that particular user (mailbox).  To rebuild it you first make sure that mailbox is not in use by Pegasus Mail (existence of a file named MAILBOXP.LCK indicates that the mailbox is in use but does not exist in all cases so may not be relied on as the only indicator).  You then rename PMAIL.INI to something like PMAIL_INI.BAD.  When Peg next starts for that user it will prompt for configuration.  Configure all settings as if doing a new install (no need to recreate POP3 and SMTP hosts).  Once done, close Pegasus Mail.  It will have created a new PMAIL.INI file and will write the configuration settings to it as part of its shutdown process. 

Hint:  A printout of the old PMAIL.INI file can be valuable as a reference during configuration.

[/quote]

Thanks a lot, Brian

The account has been behaving itself since I last mentioned it. If/when it happens again I will do as you suggest and set it up from scratch and let you know how it goes.

Thanks to you both for your help. I appreciate it :) 

Cheers! 

I think I've discovered what is causing this. We still see it, though not as frequently as before.

Since we replaced our XP stock with Win7 machines our network has been jittery - random drop-outs, stalls etc (we never saw these under XP). This does not happen across the entire network. It randomly occurs with any client machine. When a stall occurs on a machine Pegasus Mail is fine. When a drop-out occurs Pegasus Mail is unable to continue working properly after the connection is re-established - we'll see messages staying on the screen after the send button has been clicked or unable to create new folders. Sometimes, Pegasus Mail can be closed and opened again without problems but other times it will reset itself.

I have a Q open on Microsoft's forums and have tried various suggestions for registry changes that control the frequency with which other machines are polled. While one of these settings has improved the situation, it has not cured it. So, perhaps the way the network drops out and then comes back prevents Pegasus Mail from reading the ini files.

Consider using UNC paths to the server if you don't.  This removes drive mapping issues from the equation.

[quote user="Brian Fluet"]

Consider using UNC paths to the server if you don't.  This removes drive mapping issues from the equation.

[/quote]

Thanks, Brian.

We have been using DFS for several years now. The path to the exe is \\domain.local\IT\Pmail\winpm-32.exe so no drive mapping used for that. We have always used UNC paths for dedicated services so that all staff get the same service.

I am resurrecting this old thread because I have encountered the same problem.  It has begun occurring on one PC of the eleven in the office.  The behavior is as if Pegasus Mail, releases the .lck file but leaves a munged .ini file on shutdown.  On startup, a message is displayed stating something to the affect that Pegasus Mail must reset the font.  I have never seen that message before and don't know what is causing it.  Suggestions welcome.

Greenman, do you remember whether you identified the cause of your issue?

Hi, Brian

That font message is the same indicator we see here. The issue continues to affect the same computer and about a year ago one other exhibited the same symptoms. The staff who use them know to look out for the error message and I simply spend a minute restoring their settings via Options. I have no idea what causes it and because the fix is so fast I decided not to waste more time on it.

If you manage to identify the reason please let us know.

Thanks.

I am always suspicious of font problems as they indicate something not quite right with the printer. Either a printer queue or a printer driver problem. In either case Pegasus Mail is not directly involved if the print job has spooled the work to be printed. I would look at the location of the printer being used, and the path taken from the PC via the network to the actual printer.  Plan B, try using the standard (Generic) Text printer for a while, just before closing the machine down.

Martin

I makes sense that the font notice could be a printer driver issue.  The question now is whether that could be tied into the loss of configuration settings or whether we need to be troubleshooting two issues.

Brian et al,  I just did a quick shutdown of Pegasus Mail and the following files all had that exact date & time of the shutdown:

Cache.pm, Desktop.pm0, Folstate.pm, Hierarch.pm, Newcache.pm, and State.pmj  all these files in the NewMail directory.  I did not update Pmail.ini so its time & date was still yesterday's date

As this collection of files is tracking the various settings for Pegasus Mail, I would suspect that there is something going on with the saving process. Something like the files are being closed before the databuffer is fully written (ie a timing problem ?) . This might lead to a network problem.  So where are these files held on, the user system, or network ?  One solution would be to run a backup job for these files before shutting down, so that a restore could be quickly run if problems were showing up.

Martin

Me and Greeman have user mailboxes on a server and I think I speak for Greenman when I say that we suspect failure of the config file writes on shutdown but neither of us can figure out what is causing it.  It came started out of the blue on the one PC that is having the problem.  It is a Win7 PC configured the same as numerous others in the office with all the same updates.  We recently had a server failure and had to move Pegasus Mail and the mailboxes to a different server but the Pegasus Mail startup problem started some days later so I don't think the two are related.  I have created a troubleshooting list and plan to test one at a time each time the problem occurs.  The problem is sporadic so difficult to troubleshoot.

Yes - as Brian says, because the problem is intermittent it is very difficult to determine what the cause may be.

Both machines that are affected in our office each have different default printers, although both have access to the same two printers. Both are attached directly to the network, but one is shared via a server and the other is connected directly to a client over the network via a setup program.

[quote user="irelam"]Cache.pm, Desktop.pm0, Folstate.pm, Hierarch.pm, Newcache.pm, and State.pmj  all these files in the NewMail directory.  I did not update Pmail.ini so its time & date was still yesterday's date[/quote]

These files, along with pmail.ini, show the date/time stamp of the last shutdown so they are getting written.  I just seems that there is something in how pmail.ini is written that is causing the problem.  It is obvious that pmail.ini is not completely hosed because the behavior is not like a startup when a pmail.ini file does not exist.  It's just the display of the font notification message and the loss of some configuration settings (not ones that were changed during the previous session as one would expect from a failed pmail.ini update).  Copyself settings are always lost but I have not paid enough attention to say whether any other settings are consistently lost.