[quote user="Brian Fluet"]

What you are seeing is what I suspected.  Pegasus Mail uses internal IDs for tracking just about everything associated with the folder list so it is not surprising there is a conflict with "My mailbox".  You have nothing to lose except time by trying manual edits to the HIERARCH file just be sure you have a backup of the mailbox directory that you can readily restore if needed.

This may be more information than you care for but it will give you some idea of what you are dealing with (credit to Bob Kellock for these details):

Note that when Pmail is opened it reads HIERARCH into memory and operates on the memory version of it. While running, it only updates the disc version if a significant change is made such as adding or deleting a folder ; trivial changes such as expanding or collapsing a tray do not cause the disc file to be updated but any such changes that have been made appear in the disc file when it is updated due to a significant change. HIERARCH is always updated on closing Pmail even if no change has been made during the session.

When Pmail is opened  it reads the header of every PMM to extract the  folder’s UniqueID  to see if there a folder entry in HIERARCH that has the matching UniqueID in field 3. If  field 5 of that entry in HIERARCH is Name_Unavailable then it gets replaced by the folder’s title from the header of the .PMM.

It also checks that, for each folder entry in HIERARCH,  that  there is a PMM (see Note 1)   with the same UniqueID in its header that matches the UniqueID, in field 3, of the folder entry. If no match is found then the title, in field 5 of the HIERARCH entry is replaced by Name_Unavailable.

Thus folders which previously had valid entries in HIERARCH but for which the PMM no longer exists are invalidated by the insertion of Name_Unavailable. Conversely where PMMs have “reappeared” they are made valid and they return to the same tray as they were previously (or directly under the mailbox where they were not under a tray).

Furthermore any PMMs found that have a corresponding PMI and do not have any type of entry in Hierarch are entered in HIERARCH as direct entries under the mail box (i.e. not in a tray) provided that there isn’t already an entry in HIERARCH with a matching UniqueID to that in the header of the PMM.

[/quote]

Thanks for that explanation - it was a great help in understanding what I was doing.

 I ran into another kind to folder. A folder (envelope) appeared at the under My Mailbox that had no name. I use r-click [folder information] to find out that it was caused by MAIN (2).PMM, which I changed to MAIN (2).PMM.OLD. The folder remained but this time it was cause by JUNK (2).PMM which I changed accordingly. Now the folder icon is gone.I still have files named MAIN (2).PMM and JUNK( 2).PMM but no icons on the interface.

With my tray structure looking good I added my Gmail account as ISAM. I am confused about it that but that is a different problem so I will start a new thread.

Brian, I think my issue with file structure is fixed -- so again thanks.

Interesting comments, Christopher.    I have not carried out Registry cleaning, tune-ups, etc.,  the machine is just used for basic activities.  The Disc Clean-Up is a Microsoft utility, the other was recommended by our local computer shop.    Various web pages describe it as an upgrade to the OS defrag utility and do not report any problems in its use.    They have only been used two or three times on my Win 7 Pro machine, so any problems were not noticed previously.   
Happily running Check Disk appears to have cured the problems and PMail opens as usual, although I've just noted the desktop icon for Auslogics is basically white.

Rodney Fry

Thank you for the help. I am so sorry to hear of the passing of Mr Stevenson. Like the rest of you he was so very helpful and gave a lot to the forum and Pegasus Mail. I didn't think it has been 4 years

Known issue.  Developer is aware of it and should have it fixed in the next release.  See this discussion:

http://community.pmail.com/forums/thread/45232.aspx

Subject: Private Message: PM 4.71 and your great xclose32 Plugin (community.pmail.com)

I received the email yesterday 22 Feb 2016.  I'm confident it was posted recently because I have otherwise contacted the author.

 - Vince

As far as I know, the option "Deleting the search results at the end" = "Sucherergenisse beim beenden löschen" (german translation) is not working correct. Ist realy hard to delete each for this pseudo-foldes maualy

You will find all of this remaining "folders" in the file Hierach.pm (naming at least in the German version!) 

Please search for "Bisherige Sucher" (german) = "recent searches" (??) and delete them manualy.

But his will only change the place of the pseudo-folders to the bottom 

 Geraldo, using PM more than 15 years - awwaiting Version 5 

I posted this a couple of weeks earlier on the PM-Win list.

I recently upgraded from Windows 7 to Windows 10 Home. Pegasus works OK with no issues apart from when I close the program (either with the cross in the top corner or file/exit) the desktop doesn't always refresh and I am left with most of the Pegasus window showing even though the program itself has closed and disappears from the taskbar. I have to either click on one of the other programs on the taskbar, open another program, or select 'refresh' from the right menu from an exposed area of the desktop - ie anything else that causes the desktop screen to be refreshed. It doesn't usually occur if there is already a full screen program opened underneath Pegasus.

Although I have found on the web a similar effect with other programs (with no solution) and it seems not to be confined to Windows 10, on my computer Pegasus is the only program which shows this anomaly.

 A mild annoyance but which it would be nice to have a solution. Maybe I will have to wait for Pegasus 5 (2017, 2018, who knows).

Dave

[quote user="David Harris"]

I am working on a tool that will simplify the process of moving mailboxes around by doing all the necessary patching and file adjustment for you, but it won't be ready in time for v4.72. I wanted you to know that I'm aware of the issue though, and that there is a fix on the horizon.

[/quote]

Such a tool would be extremely useful indeed.

May I ask whether you plan to release it as a standalone utility or bundled in some future release of Pegasus mail?

Thanks in advance and all the best,

  Corrado

If you select multiple messages then hit F12 the properties window of the next selected message automatically opens when the existing one is closed but this is still a manual process.  I am not aware of a way to automate the removal of the "Is urgent" flag or to tell Pegasus Mail to disregard it when displaying in folder lists.

The most likely answer is that they fixed it.

The initial error suggested the problem was temporary/transitory (a 4xx code) and that the issue was with a remote server rather than Pmail.

Hope it remains fixed.

Thanks Michael, I was a little at sea,

Ron

Brian, you prompted me to do some experimenting, using new test messages in new test folders and with new simple annotations - so results are clear. I checked what was happening with files in the user Pmail/Mail directory each time. The results are:

- (Re your query) Moving a previously annotated message - now with the annotation absent - back to the new mail folder from a temporary folder does not re-establish links to the orphaned annotations.

-  Moving a still-annotated message back to the new mail folder from a temporary folder works fine and it appears there complete with the annotation.

- Green dots, indicating the existence of annotations, work exactly as one would expect they should i.e. once a message gets an annotation the green dot exists until the message is finally deleted, including in copies and following moves between folders.

-  Deleting a message with linked annotation from the new mail folder (i.e. a .CNM) or from another folder (i.e. a .PMM/.PMI) deletes any associated annotation, without leaving orphaned .PMN annotation files behind i.e. exactly as one would expect. (Note: To be clear, I did no direct editing of Pegasus files using Windows; always using Pegasus menus).

- Deleting a message that has an orphaned annotation 

(i.e. a .CNM or .PMM/.PMI exists as well as a previously associated .PMN in the user's Pmail/mail folder) - leaves the associated orphaned annotation behind.

- Re-indexing a test folder after moving a message out to the new mail folder - or to any other folder - caused the message to reappear in the test folder, complete with green dot but without the original annotation. It also exists in the folder to which it has been moved, but in that case the annotation is still attached (unless re-indexing has also occurred in that folder).

- Recovering deleted space, without subsequent re-indexing, has no impact on annotations. Recovering space and then re-indexing seems to prevent a moved message reappearing, so the question of associated annotation is irrelevant.

- Whenever an annotated message is moved (without re-indexing), its long Hex .PMN filename is changed.

- The impact on annotations of moving messages between folders is the same as copying messages between folders (as one might expect).

- Searching for references to the names of annotation files throughout the user's Pmail/Mail directory (i.e. checking in file contents), brings up no relevant results. However, as a link clearly does exist originally between the message file and its annotation, which was when I checked then I think Brian's conclusion that the link is encoded somehow in the relevant files.

Overall conclusion: The potentially very useful note-taking facility of annotations is fatally flawed by (a) the fact that re-indexing breaks the link between message and annotation and (b) the absence of any facility to remake these important links and indeed the lack of information on how to identify which orphaned annotation file belongs to which message file.

As an afterthought, the reappearance of previously deleted or moved messages upon re-indexing should ideally be addressed at some stage.

Likewise - it would appear that upgrading carries the bug over to 4.7.

anyone has a clue?   This is getting a problem, I can't file messages so the inbox gets overloaded :-(

There is a bug in the queue manager of v4.71 that results in the following behaviours:

1.  The queue manager window no longer automatically refreshes.  A refresh requires a close then open.

2.  The send now button does not actually send the messages.  I only converts them to final form.  A second click of the send button is required for final form messages to actually be sent.  IIRC, a refresh is required to see the final form messages.

There is a long discussion about this issue in this thread:

http://community.pmail.com/forums/thread/45231.aspx

Thanks..I will give it a look see

Thanks again

http://community.pmail.com/files/folders/pegadd/entry45339.aspx

Just noticed there are several identical pairs of folders. No idea how this happened, maybe when the hierarch file was rebuilt? There was one instance of 3 identical folders - when I clicked on one of them, Peg crashed and deleted all of them. So now I'm afraid to click on any of these. Wondering where to go from here, with the whole folder situation seeming to be such a mess.

Thanks Brian.  I knew there had to be a way to search a system file for my "hidden" file location, but I was never diligent enough to scan the documentation to find the right file.

Thanks to you, I now have it.

I'll also give your coding scheme a try. 

I've been using ISO-8859-1 forever and am now realizing that there are many special characters, especially foreign ones, that display only in UTF-8.

Before changing the default MIME character set in Pegasus are there any reasons not to use UTF-8 in 2016?

(Note that I still send only text emails)

Tnx :-)

Russell