I've just updated to 4.51. Perhaps this is the reason I'm not sure but I've also just discovered the archiving method described here.
The problem is that it doesn't work for me and I've tested this time and time again with the same results. In fact so many tests my head is spinning. :)
Here is an example of one test.
Start by creating by adding a new mailbox to the list. Enter a folder eg. E:\test1
Copy any folder to the new mailbox and disconnect.
Reconnect - it's fine.
Simulate pulling the archive to my HDD. Put it somewhere else. D:\myarchive. It won't connect to this. In fact it won't connect to any folder other than the complete path it was saved to.
I then try PMRestArch.exe to copy to another folder. This sometimes works. If it does I try to do it again to another folder. This doesn't work and what's more eventually the first copy fails. Eventually the original fails to read (circumstances I'm unable to determine yet suffice to say in the course of creating other copies). Once the failure occurs there's nothing I seem to be able to do to correct it yet the orginal archive is intact due to zipping in the first instance.
I really can't figure out why it's happening or what triggers it to stop however, once it does I'll never get a reconnect ever again. I have to start the test from scratch.
In case the orginals were being written to I had protected them by zipping them so I could restore but this proved to be futile. So I'm guessing that what ever is happening is internally in Pegasus.
I really have little idea what's actually going on but it appears that this method is too unreliable to trust but I am getting to the point where I need to slim my database down - it has all my emails dating back to the mid 90s and getting large..
All I've been able to determine for sure is :
1) Without using PMRestArch.exe the folder that you archive to must be exactly the same as the one you restore to. Drive, path and filename.
2) PMRestArch.exe appears to allow a change of location but I can't do it more than once and it soon fails due presumably to something Pegasus is doing internally.
Question is if I've stumbled across a problem with this version of Pegasus. Can anyone confirm this unreliable behaviour using 4.51?
EDIT:
I've now found a way to connect to the archive which is reliable, albeit using a different method. The same archive that I can't connect to is still intact and readable using this method and the bonus is the Folder trays and structure are intact.
The way to do this is to connect as a different user. Use pconfig.exe
1) Restore your archive to a folder making sure read attributes are set on all files if it came from CD / DVD
2) Folder MUST be within PMAIL. eg. E:\Pmail\Archives. However, any folder drive is acceptable as long as it is within PMAIL
3) Run Pconfig and set the user to E:\Pmail\Archives and the newmail to E:\Pmail\~8
4) Run Pegasus and you will now see the archives intact
So far this appears to be 100% reliable
<P>I've just updated to 4.51. Perhaps this is the reason I'm not sure but I've also just discovered the archiving method described here.</P>
<P>&nbsp;The problem is that it doesn't work for me and I've tested this time and time again with the same results. In fact so many tests my head is spinning. :)</P>
<P>&nbsp;Here is an example of one test.</P>
<P>&nbsp;Start by creating by adding a new mailbox to the list. Enter a folder eg. E:\test1
&nbsp;Copy any folder to the new mailbox and disconnect.</P>
<P>&nbsp;Reconnect - it's fine.</P>
<P>&nbsp;Simulate pulling the archive to my HDD. Put it somewhere else. D:\myarchive. It won't connect to this. In fact it won't connect to any folder other than the complete path it was saved to.</P>
<P>&nbsp;I then try PMRestArch.exe to copy to another folder. This sometimes works. If it does I try to do it again to another folder. This doesn't work and what's more eventually the first copy fails.&nbsp;&nbsp;Eventually the original fails to read (circumstances I'm unable to determine yet suffice to say in the course of creating other copies). Once the failure occurs there's nothing I seem to be able to do to correct it yet the orginal archive is intact due to zipping in the first instance.</P>
<P>I really can't figure out why it's happening or what triggers it to stop however, once it does I'll never get a reconnect ever again. I have to start the test from scratch.</P>
<P>In case the orginals were being written to I had protected them by zipping them so I could restore but this proved to be futile. So I'm guessing that what ever is happening is internally in Pegasus.</P>
<P>I really have little idea what's actually going on but it appears that this method is too unreliable to trust but I am getting to the point where I need to slim my database down - it has all my emails dating back to the mid 90s and getting large..</P>
<P>All I've been able to determine for sure is :</P>
<P>1) Without using PMRestArch.exe the folder that you archive to must be exactly the same as the one you restore to. Drive, path and filename.</P>
<P>2) PMRestArch.exe appears to allow a change of location but I can't do it more than once and it soon fails due presumably to something Pegasus is doing internally.</P>
<P>&nbsp;Question is&nbsp; if I've stumbled across a problem with this version of Pegasus. Can anyone confirm this unreliable behaviour using 4.51?
</P>
<P>EDIT:</P>
<P>I've now found a way to connect to the archive which is reliable,&nbsp;albeit using a different method. The same archive that&nbsp;I can't connect&nbsp;to is still intact and readable using this method and the bonus is the Folder trays&nbsp;and structure are intact.</P>
<P>The way to do this is to connect as a different user. Use pconfig.exe</P>
<P>1) Restore your archive to a folder making sure read attributes are set on all files if it came from CD / DVD
2) Folder MUST be within PMAIL. eg. E:\Pmail\Archives. However, any folder drive is acceptable as long as it is within PMAIL
3) Run Pconfig and set the user to E:\Pmail\Archives and the newmail to E:\Pmail\~8
4) Run Pegasus and you will now see the archives intact</P>
<P>So far this appears to be 100% reliable&nbsp;</P>