Michael -- IERenderer's Homepage PGP Key ID (RSA 2048): 0xC45D831B S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C
If you're referring to where Pegasus saves "temp files" (attachments?), the location isn't specific to XP, but where that is (if it is), is above my pay grade's "need to know" level.
Michael -- IERenderer's Homepage PGP Key ID (RSA 2048): 0xC45D831B S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C
Cool Michael - does a pay raise come with the promotion?
If Don turns off automatic message retrieval, and then discovers that retrieving culprit messages works OK with the AV disabled first, but still get whacked if AV is not disabled, I'm starting to think maybe a different AV for Don might be the answer..
Or..maybe something like OE Classic might work instead of using Pegasus (the only reason I think it might is because of the race-condition with AV's scanning, being either a little faster or slower maybe), but more likely it won't make any difference..
At the least, he knows that if he sees the problem occur, he can move the message to another folder (or "delete" it to the deleted mail folder) and then move it back to the New Mail/Inbox folder and it will then display correctly.
Here's another thought.. Selecting Tools > Spam and Content Controls > Content Control> ADD...
Name: (Whatever..)
Choose Only messages originating from the Internet...
Click Actions Tab, Do This: select Move the Message to a folder, click SET, and select the New Mail folder, and then Click OK
This is what Pegasus does anyway, but the different processing process executing the rule might just be the ticket to avoid the race condition without affecting the functioning at all.
And hey! Is there a function that will trigger Pegasus to execute if a message appears in a particular mail folder.. to move it to a different folder?
If so, instead of selecting the "new mail" folder as the destination above, create a temp folder, put the messages there, and then Pegasus automatically sees them in the trigger "temp" folder and moves them to the "new mail" folder. We already know that bandaid works, we just need to automate it somehow?
If Pegasus Mail 'About' info shows the temp directory as the system temp directory you can change that by editing the PMAIL.INI file, editing the path in every "Temporary files directory". So, to specify C:\Temp\PM_Temp as the Pegasus Mail temporary directory you would:
Note: Manually editing the PMAIL.INI can result in unintended issues. If you encounter any oddities when you next start Pegasus Mail, restore PMAIL.INI to the safety copy.
Don hasn't told us yet if it's only affecting messages with a particular characteristic (sender, attachment, or ?). He may be trying to isolate that..
It would be interesting to see if a different temp directory works.. I suspect not, as AV is probably triggered by a disc write so the location is not relevant if AV is scanning the location anyway ..
But.. if AV can be set to ignore a unique directory (or drive) when retrieving email, or completely, then that might work too, as long as he doesn't mind the vulnerability of an unscanned attachment.
But.. if AV can be set to ignore a unique directory (or drive) when retrieving email, or completely, then that might work too, as long as he doesn't mind the vulnerability of an unscanned attachment.
Actually, I think best practice is to exclude the mailbox directory from active scanning but to include the temp directory. Attachments get extracted to the temp directory when being opened so will get scanned at that moment. An even better practice with attachments is to save them, scan the saved file, and then open but I will only do that if I need the file but have some suspicion about it.
Actually, I think best practice is to exclude the mailbox directory from active scanning but to include the temp directory. Attachments get extracted to the temp directory when being opened so will get scanned at that moment.
Unfortunately it doesn't solve Don's problem, Brian (oh, I do dislike the prospect of disagreeing with you, but here goes..) - apparently AV is scanning incoming while Pegasus is trying to build the new mail list and is blocked from gathering the data at that time.
So, the temp directory has to be excluded from scanning, or Pegasus has to be delayed from trying to build the new mail list until AV is done with the scanning and lifts the lock allowing Pegasus access to it.
So, the temp directory has to be excluded from scanning, or Pegasus has to be delayed from trying to build the new mail list until AV is done with the scanning and lifts the lock allowing Pegasus access to it.
AFAIK, Pegasus Mail does not use the temporary location for building the new mail list. It uses the NEWCACHE.PM file which I believe it then appends with the information about any newly arrived message files. When problems occur with the display of subject or header, often just a refresh of the new mail folder will fix it. That said, there is a known issue with the display of UTF-8 encoded subject lines. I don't think that is what Don is dealing with though. Don has already excluded his \PMail directory from active scanning so I really don't think AV scanning is the issue. If a refresh of the new mail folder fixes the issue, and the issue is only occurring randomly, then I think Don is just dealing with a random anomaly.
This discussion has gotten so long that it might be best for Don to start a new one with current info if he hasn't found a solution or work around.
Aye - first..
..perhaps we need to ask for more detail if my assumption that it is the same problem isn't correct.
His desire to turn off automatic retrieval of messages looks like the first step in my earlier suggestions last July for further troubleshooting - keeping a suspect email from being pulled down from the mail server until AV could be turned off first to verify AV was the problem..
I was going to suggest "refreshing" the new mail folder, but I wasn't sure that would actually "rebuild the list" (newcache?) or even how to do it (Does just clicking on the "new mail" folder do that? I have no way to test it without mucking with the file manually, if that is indeed where the message list is built from..), so I just deleted that from an earlier comment.
This discussion has gotten so long that it might be best for Don to start a new one with current info
As I started off this reply... "Aye".
OK, then open Tools > Options > Advanced Settings, and set "Refresh new Mail Folder view every __ secs" to "-1"
This will disable new mail polling altogether - the new mail window will only be updated when you explicitly choose New mail from the File menu, or click the New mail Icon in the toolbar.
The latter implies that action refreshes the New Mail folder, but as I noted in my earlier reply, it may not force a list update (update the NEWCACHE.PM file?), which is what you would desire if you wanted to repoll the "Inbox" and have Pegasus look at the messages again and get the data this time.. It may just rescan the same (corrupted) data list.
Then again - it might work. One way to find out is, when you see one of "those" messages click the Icon (or click it again).. and see what happens.
Brian raised a good question to ask - is this the same problem you were having a couple months ago (Message is listed with "???" for "From" and "None" in the subject)?
If moving the message to a different folder and them moving it back to the inbox works to fix the message, then..
..you can create a RULE (click the green funnel in the tool bar) , select ADD rule, and then set conditions (Message Header From = "???" ) and have it move that message to a "FixIt" folder.
Then, set another rule to move all messages in the FixIt folder back to the New Mail folder.
For assistance, click the Help Icon in the "New mail Filtering rules" window, for example..
Using rules to filter the contents of any folder
(You will probably have to play with the rule configurations a bit to get it to work, I haven't tried them with Pegasus)
@Steeley, regarding NEWCACHE.PM, I misspoke earlier when I said "I believe it then appends with the information about any newly arrived message files". It does not. NEWCACHE.PM is created at Pegasus Mail shutdown and deleted on Pegasus Mail startup. Its purpose is solely to speed up the display of the new mail folder content by holding a cache of the messages that were in it at last shutdown. Something that I do not know is where the content of the new message folder is maintained. I have never been able to identify a file that holds it. I do know that a refresh of the new mail folder requires that it be closed and then opened. Interestingly, a NEWCACHE.PM file is not created when the new mail folder is closed, only when Pegasus Mail is closed. So, there is some mechanism by which Pegasus Mail keeps track of all read new messages. A refresh causes it to poll the .CNM files of unread messages, obtaining the data that it needs for the new mail folder list entry. The result is that a failed poll when the .CNM file first arrived (one that results in invalid data in the new mail folder entry) could be corrected on the refresh poll. Moving a message to a folder and then back to the new mail folder has the same effect.
Don, there is no "auto-retrieve" mechanism within Pegasus Mail other than from hosted mailboxes via the internet
I think Don is trying to perform the troubleshooting I suggested back in my post Jul 1 at 3:48 pm
The idea was to keep a suspect message on the mail server, turn off AV, and then bring it down manually (using File > Selective mail download), and see what happens while you're watching and stepping through the process manually.
However, I have no idea how mail is obtained if it's not via the "internet" (or equivalent on a LAN), so that is the first question to be answered (after Don confirms we're chasing the same problem as before).
What is clear, assuming the same problem, is that the first time the message ends up (pull or push) in the new mail folder, Pegasus knows it's there and shows it's there, but is unable to scan the file for pertinent information to display, But, once the new mail folder is refreshed (by changing the parameters of the message / changing a property of it, or moving it to another folder and back), voilla.. whoop! There is IS..
In other words, something somewhere is happening during the process that first puts a message into the New Mail folder that is blocking Pegasus from doing what it needs to.. AV scan is the best guess. After that, refreshing the message or new mail folder by altering the message in some way rescans the message without outside interference and sanity is restored to the new mail folder contents display.
The simplest thing to check off the troubleshooting checklist is just click the New Mail ICON and see if that fixes the message display. My guess is not, but it's really easy to prove that works or doesn't. And then we can move on to the next step (whatever that is in a non-internet mail environment) or take a victory lap.
Michael -- IERenderer's Homepage PGP Key ID (RSA 2048): 0xC45D831B S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C
So am I.. works for me.. (windows 10 and Chrome v, 128.0.6613.138 (Official Build) (64-bit)).
At this point it's probably best to start a fresh thread as Bryan suggested as this one has wandered far and wide in search of a resolution.
Maybe "Unreadable Mail Unknown "From" and "None" Subject, Part II"
Summarize Problem, Operating system, pertinent details (LAN/WAN type, email distribution {using Mercury???}, etc..)
Your previous draft for topic is pending
If you continue, your previous draft will be discarded.