Pegasus Mail Suggestions
Compressing folders

[quote user="Barius"] (e.g. NTFS) can easily handle the number of email files a user is likely to accumulate over the lifetime of their computer. 
[/quote]

 I suspect I'm not the only Pegasus user for whom emails are transferred when I upgrade my PC...   Its so easy to do!

 
The only way I could see storing messages as files working would be for each folder to be a sub directory of the mail box.   I guess that would bean that all folders by default could contain both Messages and sub folders but how would I import all my email when I upgraded....
 

<p>[quote user="Barius"] (e.g. NTFS) can easily handle the number of email files a user is likely to accumulate over the lifetime of their computer.  [/quote]</p><p> I suspect I'm not the only Pegasus user for whom emails are transferred when I upgrade my PC...   Its so easy to do!</p><p>  The only way I could see storing messages as files working would be for each folder to be a sub directory of the mail box.   I guess that would bean that all folders by default could contain both Messages and sub folders but how would I import all my email when I upgraded....  </p>

Is it possible to have folders with deleted mails compressed silently in the background?

I have one large folder with emails that have attachments, most of them 2+ MB.

Every time I delete one email, I have to wait... wait... wait ...until compression is completed. 

 

By the way: The standard "size" of deleted mail is 24000 bytes. In this day of Zillion Gig hard disks, what would be a "good number"?

 

Arthur

 

<p>Is it possible to have folders with deleted mails compressed silently in the background?</p><p>I have one large folder with emails that have attachments, most of them 2+ MB.</p><p>Every time I delete one email, I have to wait... wait... wait ...until compression is completed. </p><p> </p><p>By the way: The standard "size" of deleted mail is 24000 bytes. In this day of Zillion Gig hard disks, what would be a "good number"?</p><p> </p><p>Arthur</p><p> </p>

You can set it to 0 (zero) and it will never compres, lthough I woul'n't recomment that in normal cases, but sometimes it can be handy.

You can recover deleted space using the folders rightmouse function.

 BTW my value is set to 500000

 

<P>You can set it to 0 (zero) and it will never compres, lthough I woul'n't recomment that in normal cases, but sometimes it can be handy.</P> <P>You can recover deleted space using the folders rightmouse function.</P> <P> BTW my value is set to 500000 </P> <P mce_keep="true"> </P>

-- Han van den Bogaerde - support@vandenbogaerde.net Member of Pegasus Mail Support Group. My own Pegasus Mail related web information: http://www.vandenbogaerde.net/pegasusmail/

"Zero" would not be an option for me. I would simply forget to compress. [:$] And I have a lot (and I do mean A LOT) of folders.

Given the size of the attachments (in that one folder) and the size of my HD I set the number at 100000 for now. 

Thanks for your suggestions!

 

Arthur

 

<p>"Zero" would not be an option for me. I would simply forget to compress. [:$] And I have a lot (and I do mean A LOT) of folders.</p><p>Given the size of the attachments (in that one folder) and the size of my HD I set the number at 100000 for now. </p><p>Thanks for your suggestions!</p><p> </p><p>Arthur</p><p> </p>

[quote user="Arthur van Haarlem"]Is it possible to have folders with deleted mails compressed silently in the background?[/quote]

Not really - or at least, not with the code as it stands at present. Folder compression works at the raw data level, and the consequences of anything interfering with the process (for instance, by trying to add new messages to the folder while the compression was occurring) are quite bad.

I do agree that the delay when a large folder gets compressed can be quite annoying, though. I'll make a note that I should try to think of some less intrusive way of doing this.

Cheers!

-- David --

<p>[quote user="Arthur van Haarlem"]Is it possible to have folders with deleted mails compressed silently in the background?[/quote]</p><p>Not really - or at least, not with the code as it stands at present. Folder compression works at the raw data level, and the consequences of anything interfering with the process (for instance, by trying to add new messages to the folder while the compression was occurring) are quite bad. I <b>do</b> agree that the delay when a large folder gets compressed can be quite annoying, though. I'll make a note that I should try to think of some less intrusive way of doing this. Cheers! -- David -- </p>

Tbird solves the problem by storing emails in separate files.  In the past this would have been a drawback due to filesystem limitations, but modern filesystems (e.g. NTFS) can easily handle the number of email files a user is likely to accumulate over the lifetime of their computer.  Simple databases like sqlite provide quick search and indexing.  IMHO, one of the best features of Pmail back when the only competition was Outlook, was the fact that it stores separate folders in separate .pmm files.  It mitigates the risk of corruption considerably.  If Pmail used separate files (by default), I would imagine it would make compression much easier (I am not an expert, of course).

Tbird solves the problem by storing emails in separate files.  In the past this would have been a drawback due to filesystem limitations, but modern filesystems (e.g. NTFS) can easily handle the number of email files a user is likely to accumulate over the lifetime of their computer.  Simple databases like sqlite provide quick search and indexing.  IMHO, one of the best features of Pmail back when the only competition was Outlook, was the fact that it stores separate folders in separate .pmm files.  It mitigates the risk of corruption considerably.  If Pmail used separate files (by default), I would imagine it would make compression much easier (I am not an expert, of course).

[quote user="Barius"]Tbird solves the problem by storing emails in separate files.[/quote]

Does it?!? I'm truly amazed - I abandoned that approach over a decade ago as costly, slow and inefficient. There's far more to storing mail this way than just the number of files, although that can get pretty hairy pretty fast - there's fragmentation, parsing, file access issues... All told, it's a pretty inefficient way of working, and I'm really surprised that Thunderbird would have gone for it.

Cheers!

-- David --

 

<p>[quote user="Barius"]Tbird solves the problem by storing emails in separate files.[/quote] Does it?!? I'm truly amazed - I abandoned that approach over a decade ago as costly, slow and inefficient. There's far more to storing mail this way than just the number of files, although that can get pretty hairy pretty fast - there's fragmentation, parsing, file access issues... All told, it's a pretty inefficient way of working, and I'm really surprised that Thunderbird would have gone for it. Cheers! -- David --  </p>

Haha, funny guy, but it seems I did speak out of my ass.  I'm sure back in v1.0 they were using separate files, though maybe I just had it setup differently...  I know for sure they were separate though because I had to write a perl script to stitch them all together with ^Z's into .pmm files for Pegasus.  I installed v2.0 tonight and they seem to be using some form mbox now.

Still, I think you're misunderstanding somewhat.  What I was pointing out is that a db like sqlite would contain most (if not all) of the data to provide faster indexes (searching), while the emails are stored separately and only accessed to get the full-body content or attachments.  This is basically how the desktop search engines work (Copernic, Google).  In this scenario, I can't see how fragmentation would be a bigger concern than compression is currently; parsing is 'trivial' as it only needs to happen once when the file is indexed into the db; file access shouldn't be an issue as the user can only access the full body of a handful of emails at one time; the number of files isn't much of an issue anymore, though if you're paranoid just make directories for each pmail folder.  The advantage is that there is less chance of losing large numbers of emails if a part of the disk fails.  It's easy for a large file to be entirely lost because of just a small number of bad clusters (some of my .pmm files are >1Gb), the risk is mitigated when the files are separate.  Database corruption isn't a problem as it can be rebuilt.  Further, with each email stored separately, other search engines like that built into Vista can easily index the emails for searching and presentation within a more integrated environment.

Anyways, I am not an expert, not...an...expert (at email systems).  Anything I say in regards to design should be regarded as an idea 'thrown out there' to be consumed with copious amounts of salt.


<p>Haha, funny guy, but it seems I did speak out of my ass.  I'm sure back in v1.0 they were using separate files, though maybe I just had it setup differently...  I know for sure they were separate though because I had to write a perl script to stitch them all together with ^Z's into .pmm files for Pegasus.  I installed v2.0 tonight and they seem to be using some form mbox now.</p><p>Still, I think you're misunderstanding somewhat.  What I was pointing out is that a db like sqlite would contain most (if not all) of the data to provide faster indexes (searching), while the emails are stored separately and only accessed to get the full-body content or attachments.  This is basically how the desktop search engines work (Copernic, Google).  In this scenario, I can't see how fragmentation would be a bigger concern than compression is currently; parsing is 'trivial' as it only needs to happen once when the file is indexed into the db; file access shouldn't be an issue as the user can only access the full body of a handful of emails at one time; the number of files isn't much of an issue anymore, though if you're paranoid just make directories for each pmail folder.  The advantage is that there is less chance of losing large numbers of emails if a part of the disk fails.  It's easy for a large file to be entirely lost because of just a small number of bad clusters (some of my .pmm files are >1Gb), the risk is mitigated when the files are separate.  Database corruption isn't a problem as it can be rebuilt.  Further, with each email stored separately, other search engines like that built into Vista can easily index the emails for searching and presentation within a more integrated environment. </p><p>Anyways, I am not an expert, not...an...expert (at email systems).  Anything I say in regards to design should be regarded as an idea 'thrown out there' to be consumed with copious amounts of salt. </p>

[quote user="Barius"]

Haha, funny guy

[/quote]

??  I was in no sense being "funny". My comment was a serious one, based on the fact that I had already tried what you were suggesting a long time ago and had discarded it: any humour you derived from my statement was unintentional. Remember that Pegasus Mail has been in existence for something like five times as long as Thunderbird, and more than twice as long as Outlook: during that very long life, many things have been tried and discarded.

The idea about using some kind of database to store pre-indexed information (primarily for fast searches) is one I am actively considering at the moment, but it is independent of the mechanism by which messages are stored. It is also worth noting that version 5 will support a much richer folder format that will not require compression (essentially a file system within a file system, with deleted data being automatically reallocated internally and invisibly).

Cheers!

-- David --

[quote user="Barius"]<p>Haha, funny guy </p><p>[/quote] ??  I was in no sense being "funny". My comment was a serious one, based on the fact that I had already tried what you were suggesting a long time ago and had discarded it: any humour you derived from my statement was unintentional. Remember that Pegasus Mail has been in existence for something like five times as long as Thunderbird, and more than twice as long as Outlook: during that very long life, many things have been tried and discarded. The idea about using some kind of database to store pre-indexed information (primarily for fast searches) is one I am actively considering at the moment, but it is independent of the mechanism by which messages are stored. It is also worth noting that version 5 will support a much richer folder format that will not require compression (essentially a file system within a file system, with deleted data being automatically reallocated internally and invisibly). Cheers! -- David -- </p>

Beware of opportunistic locking and caching problems when working with indexes - it is a big ms-access /foxpro/dbase/bde problem ever since winxp saw the light.

Beware of opportunistic locking and caching problems when working with indexes - it is a big ms-access /foxpro/dbase/bde problem ever since winxp saw the light.

IMHO, sqlite is the ideal solution for standalone apps like Pegasus.  I wouldn't touch MS Access with a 10' pole.

IMHO, sqlite is the ideal solution for standalone apps like Pegasus.  I wouldn't touch MS Access with a 10' pole.

Sylpheed using maildir (each email is a file ondisk), with an index file in the root directory.

The use of a db does have some good points, but how robust would it be? If there is a power fail, corrupt write would it not be possible to loose all the emails? Check out WordPerfect Mail (old Bloomba), there is common problem of index corruption, this is the same with Opera. One of the faq questions will ask you to rebuild the index if you can not access emails. Must trust the data, no corruption, lost of emails is not something a newuser would wish - make them move to another client.

Database storage with the use of views for the different folders etc would be pie in the sky, like the idea. Would that mean a change in the OS's supported? Some people are running on Win9x which can be 'interesting' to support. What of low memory machines, laptops?

Many questions, DH will work/thrashout.


Sylpheed using maildir (each email is a file ondisk), with an index file in the root directory. The use of a db does have some good points, but how robust would it be? If there is a power fail, corrupt write would it not be possible to loose all the emails? Check out WordPerfect Mail (old Bloomba), there is common problem of index corruption, this is the same with Opera. One of the faq questions will ask you to rebuild the index if you can not access emails. Must trust the data, no corruption, lost of emails is not something a newuser would wish - make them move to another client. Database storage with the use of views for the different folders etc would be pie in the sky, like the idea. Would that mean a change in the OS's supported? Some people are running on Win9x which can be 'interesting' to support. What of low memory machines, laptops? Many questions, DH will work/thrashout.

[quote user="Barius"]I'm sure back in v1.0 they were using separate files[/quote]


I've used several versions on and off, and I've never seen that.  And there is a recurring complaint going back years that some AV programs will grab the complete contents of a Thunderbird Inbox if a single infected message arrives--that indicates in itself that they're all stored in the same file.  (Besides indicating that many AV programs for Windows can't scan mail before it gets to the Inbox, unless you're using Outlook Express, and that many people leave mail permanently in their Inbox.)

[quote]I installed v2.0 tonight and they seem to be using some form mbox now.[/quote]

Yes, it does. I've looked at Thunderbird mail stores in a text editor before now and moved mbox files between different programs, including Thunderbird.

Apple's Mail, however, does use single files.  It has since OS X 10.4 shipped.  Whatever the other advantages, I think this primarily so that mail messages can be indexed by Spotlight.  (Might similar storage systems become more common, if desktop search becomes more popular?)

Problems with indexing can lead to slowing of the program over time in Mail: there's an interesting description from someone at Apple here:

http://www.friday.com/bbum/2007/03/02/vacuuming-mails-envelope-index-to-make-mail-faster/

I haven't had any real problems on OS X with Mail myself, but then I'm not really a very heavy email user.
[quote user="Barius"]I'm sure back in v1.0 they were using separate files[/quote]<DIV><BR class="khtml-block-placeholder"></DIV><DIV>I've used several versions on and off, and I've never seen that.  And there is a recurring complaint going back years that some AV programs will grab the complete contents of a Thunderbird Inbox if a single infected message arrives--that indicates in itself that they're all stored in the same file.  (Besides indicating that many AV programs for Windows can't scan mail before it gets to the Inbox, unless you're using Outlook Express, and that many people leave mail permanently in their Inbox.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>[quote]I installed v2.0 tonight and they seem to be using some form mbox now.[/quote]</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Yes, it does. I've looked at Thunderbird mail stores in a text editor before now and moved mbox files between different programs, including Thunderbird.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Apple's Mail, however, does use single files.  It has since OS X 10.4 shipped.  Whatever the other advantages, I think this primarily so that mail messages can be indexed by Spotlight.  (Might similar storage systems become more common, if desktop search becomes more popular?)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Problems with indexing can lead to slowing of the program over time in Mail: there's an interesting description from someone at Apple here:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>http://www.friday.com/bbum/2007/03/02/vacuuming-mails-envelope-index-to-make-mail-faster/</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I haven't had any real problems on OS X with Mail myself, but then I'm not really a very heavy email user.</DIV>

@aderoy

"If there is a power fail, corrupt write would it not be possible to loose all the emails?"

No, because the emails are not stored in the db, only indexing information.  The emails are stored in separate files which mitigates the risk of corruption.  If a write fails then it will only corrupt the single email that is being written out.
 

"...there is common problem of index corruption..."

There's a common problem with index corruption in Pegasus already, so what else is new?  It's not uncommon for me to have to rebuild indexes on very large mail folders at least once or twice a year.  If anything, a stable and lightweight db like sqlite should make rebuilding faster when it is necessary.


"Would that mean a change in the OS's supported?"

I doubt it, sqlite has very low requirements and runs on basically anything.  You may be thinking of a database like Oracle or MSSQL, neither of which would be a good choice for a standalone application.  SQLite and similar lightweight databases are designed to have a very small footprint.

<p>@aderoy "If there is a power fail, corrupt write would it not be possible to loose all the emails?"</p><p>No, because the emails are not stored in the db, only indexing information.  The emails are stored in separate files which mitigates the risk of corruption.  If a write fails then it will only corrupt the single email that is being written out.  </p><p>"...there is common problem of index corruption..."</p><p>There's a common problem with index corruption in Pegasus already, so what else is new?  It's not uncommon for me to have to rebuild indexes on very large mail folders at least once or twice a year.  If anything, a stable and lightweight db like sqlite should make rebuilding faster when it is necessary.</p><p> "Would that mean a change in the OS's supported?"</p><p>I doubt it, sqlite has very low requirements and runs on basically anything.  You may be thinking of a database like Oracle or MSSQL, neither of which would be a good choice for a standalone application.  SQLite and similar lightweight databases are designed to have a very small footprint.</p>

@Mike

" I think this primarily so that mail messages can be indexed by Spotlight."

I consider that a big plus now that the same feature is built into Vista.  Since the feature is available, why not make use of it?

 
"Problems with indexing can lead to slowing of the program over time in Mail"

This is true of any indexing mechanism.  However, sqlite is used by the spamhalter plugin to Mercury and Pmail.  On my Mercury server I have a 100Mb word database without any slow-down problems at all.  If spamhalter can read/write a 100Mb cache on the server-side without problems I'm sure it can handle a single users' email box.

Anyhow, I'm starting to sound like I'm advertising sqlite, there are alternatives.  My own expertise just happens to be in SQL based databases so that's what I generally refer to. 

<p>@Mike</p><p>" I think this primarily so that mail messages can be indexed by Spotlight."</p><p>I consider that a big plus now that the same feature is built into Vista.  Since the feature is available, why not make use of it?</p><p>  "Problems with indexing can lead to slowing of the program over time in Mail"</p><p>This is true of any indexing mechanism.  However, sqlite is used by the spamhalter plugin to Mercury and Pmail.  On my Mercury server I have a 100Mb word database without any slow-down problems at all.  If spamhalter can read/write a 100Mb cache on the server-side without problems I'm sure it can handle a single users' email box. </p><p>Anyhow, I'm starting to sound like I'm advertising sqlite, there are alternatives.  My own expertise just happens to be in SQL based databases so that's what I generally refer to. </p>

[quote user="Barius"]

"...there is common problem of index corruption..."

There's a common problem with index corruption in Pegasus already, so what else is new?

[/quote]

I have to say I resent this, and I especially resent the rude and rather dismissive way you say it.

I have had only a single index corruption in seventeen years of using the program, and that was directly caused by the computer crashing (not induced by my code) as the folder was being written. If you can produce a reliable scenario that results in folder or index corruption (other than running out of disk space, which I can't do much about), then tell me about it so I can fix it - otherwise, don't go around defaming a lot of hard work so casually.

With regards to mySQL - it's a good product, and I have already indicated in these forums that I intend to make more use of it in future... But it's not suitable for use as a foldering container, because of the nature of e-mail. An e-mail message may be 1K in size, or it may be 100MB, and the folder has to cope with this kind of variation efficiently. Last I checked, this ruled out mySQL (and indeed most typical databases - I evaluated several) because they expect to be able to manipulate entire records in memory. V5 of Pegasus Mail uses a technology I have developed to handle this type of data - it's effectively a file system within a file, and works very well.

-- David --

[quote user="Barius"]<p>"...there is common problem of index corruption..."</p><p>There's a common problem with index corruption in Pegasus already, so what else is new?</p>[/quote] I have to say I resent this, and I especially resent the rude and rather dismissive way you say it. I have had only a single index corruption in seventeen years of using the program, and that was directly caused by the computer crashing (not induced by my code) as the folder was being written. If you can produce a reliable scenario that results in folder or index corruption (other than running out of disk space, which I can't do much about), then tell me about it so I can fix it - otherwise, don't go around defaming a lot of hard work so casually. With regards to mySQL - it's a good product, and I have already indicated in these forums that I intend to make more use of it in future... But it's not suitable for use as a foldering container, because of the nature of e-mail. An e-mail message may be 1K in size, or it may be 100MB, and the folder has to cope with this kind of variation efficiently. Last I checked, this ruled out mySQL (and indeed most typical databases - I evaluated several) because they expect to be able to manipulate entire records in memory. V5 of Pegasus Mail uses a technology I have developed to handle this type of data - it's effectively a file system within a file, and works very well. -- David --

Haha, now you're taking me too seriously.  I didn't mean to sound at all dismissive, Pegasus is generally equal if not superior to other email clients in this respect (and fixing them is generally easy, god forbid I ever have to deal with a corruption in Outlook).  However, all clients, Pegasus included, are prone to index corruption from certain events, for example you mentioned when Windows crashes which can be a frequent occurrence for some people. 

Another issue I have personally run into is .pmm files that are larger than 2Gb.  After the 2Gb barrier Pegasus indexes become 'corrupt' (they start pulling random sections of the .pmm file), likely because the indexes are limited by a 32bit pointer.  I asked about this on the mailing lists once and was told it was a problem with Windows and not Pegasus.  I should be able to reproduce this in a desktop video if you like.

The jist of my post was simply to point out that regenerating indexes could be faster, when necessary.

"An e-mail message may be 1K in size, or it may be 100MB, and the folder has to cope with this kind of variation efficiently."

I'm not sure I understand.  My arguments above are for using a database to store metadata only, not the full body of an email.  Storing the full body negates almost all of the benefits of using a database...

BTW, I would not suggest MySQL for a standalone app, SQLite is much more efficient when a full-blown database isn't necessary.

BTW2, maybe you've considered this, but could you not use recursive indexes to create a fast and scalable 'filesystem in a database' structure?  These structures are often used in forums, wikis, calendars, etc.  It seems like it would be sensible for email too?

<p>Haha, now you're taking me too seriously.  I didn't mean to sound at all dismissive, Pegasus is generally equal if not superior to other email clients in this respect (and fixing them is generally easy, god forbid I ever have to deal with a corruption in Outlook).  However, all clients, Pegasus included, are prone to index corruption from certain events, for example you mentioned when Windows crashes which can be a frequent occurrence for some people.  </p><p>Another issue I have personally run into is .pmm files that are larger than 2Gb.  After the 2Gb barrier Pegasus indexes become 'corrupt' (they start pulling random sections of the .pmm file), likely because the indexes are limited by a 32bit pointer.  I asked about this on the mailing lists once and was told it was a problem with Windows and not Pegasus.  I should be able to reproduce this in a desktop video if you like. </p><p>The jist of my post was simply to point out that regenerating indexes could be faster, when necessary.</p><p>"An e-mail message may be 1K in size, or it may be 100MB, and the folder has to cope with this kind of variation efficiently."</p><p>I'm not sure I understand.  My arguments above are for using a database to store metadata only, not the full body of an email.  Storing the full body negates almost all of the benefits of using a database... </p><p>BTW, I would not suggest MySQL for a standalone app, SQLite is much more efficient when a full-blown database isn't necessary.</p><p>BTW2, maybe you've considered this, but could you not use recursive indexes to create a fast and scalable 'filesystem in a database' structure?  These structures are often used in forums, wikis, calendars, etc.  It seems like it would be sensible for email too? </p>

Hi !

[quote user="David Harris"] 

V5 of Pegasus Mail uses a technology I have developed to handle this

type of data - it's effectively a file system within a file, and works

very well.

[/quote] 

I think you should patent this technology and maybe sell it, which could become a source of funding. Also, if there was a foundation (whose existence I argue for in the mailing list, so I will not do that again here), it could also be possible to set up a support service that the potential buyers would have to pay for (I am merely thinking about professional institutions). This is a good funding opportunity in my opinion.

Cheers !

Ginhead. 

<p>Hi !</p><p>[quote user="David Harris"] </p><p>V5 of Pegasus Mail uses a technology I have developed to handle this type of data - it's effectively a file system within a file, and works very well.</p><p>[/quote] </p><p>I think you should patent this technology and maybe sell it, which could become a source of funding. Also, if there was a foundation (whose existence I argue for in the mailing list, so I will not do that again here), it could also be possible to set up a support service that the potential buyers would have to pay for (I am merely thinking about professional institutions). This is a good funding opportunity in my opinion.</p><p>Cheers !</p><p>Ginhead. </p>

The one thing I really like about Pegasus' folder system is that everything is stored in plain text files.  In a very worst case scenario I could at least open the files in a plain text editor and retrieve the information.  The only change I could even possibly wish for would be that I could rename the physical folder files so that when I do look under the hood (like to see what are the biggest folders)  could easily identify which folder is which.

Given how long Dave has been working on Pegasus I really do trust that he has thought about and/or tried other message storage ideas and has very good reasons for the way he does things.  Pegasus is just about the most reliable program I have ever used and this says a lot about Dave's methods. 

<p>The one thing I really like about Pegasus' folder system is that everything is stored in plain text files.  In a very worst case scenario I could at least open the files in a plain text editor and retrieve the information.  The only change I could even possibly wish for would be that I could rename the physical folder files so that when I do look under the hood (like to see what are the biggest folders)  could easily identify which folder is which.</p><p>Given how long Dave has been working on Pegasus I really do trust that he has thought about and/or tried other message storage ideas and has very good reasons for the way he does things.  Pegasus is just about the most reliable program I have ever used and this says a lot about Dave's methods. </p>

[quote user="David Harris"]
I have had only a single index corruption in seventeen years of using the program, and that was directly caused by the computer crashing (not induced by my code) as the folder was being written. If you can produce a reliable scenario that results in folder or index corruption (other than running out of disk space, which I can't do much about), then tell me about it so I can fix it - otherwise, don't go around defaming a lot of hard work so casually.
-- David --

[/quote]

I have been using Pegasus for many years - currently running v4.41 under XP Pro.  I cannot remember the last time I had a corrupted index, but yesterday it happened with a folder containing over 1500 emails.  Re-indexing worked - but I lost all the emails except the latest one in the folder!.  Fortunately I was able to recover by replacing the PMM and PMI files from my daily backup.   This got me back all the lost emails - but of course I did not get the latest one back.   I am extremely satisfied with the general reliablity of Pegasus in this respect, but I would like to hear any ideas on why the corruption occurred.  I was not aware of doing anything 'dangerous' at the time the corruption occurred.

 

<p>[quote user="David Harris"] I have had only a single index corruption in seventeen years of using the program, and that was directly caused by the computer crashing (not induced by my code) as the folder was being written. If you can produce a reliable scenario that results in folder or index corruption (other than running out of disk space, which I can't do much about), then tell me about it so I can fix it - otherwise, don't go around defaming a lot of hard work so casually. -- David -- [/quote]</p><p>I have been using Pegasus for many years - currently running v4.41 under XP Pro.  I cannot remember the last time I had a corrupted index, but yesterday it happened with a folder containing over 1500 emails.  Re-indexing worked - but I lost all the emails except the latest one in the folder!.  Fortunately I was able to recover by replacing the PMM and PMI files from my daily backup.   This got me back all the lost emails - but of course I did not get the latest one back.   I am extremely satisfied with the general reliablity of Pegasus in this respect, but I would like to hear any ideas on why the corruption occurred.  I was not aware of doing anything 'dangerous' at the time the corruption occurred.</p><p> </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Cancel
Delete
Pending draft ... Click to resume editing
Discard draft