Avoid folder corruption by updating more often

This is already possible. You only have to adjust the "WriteIndexes" setting in the "Advanced" section of YAM's configuration. The value represents the time in seconds between two index flushes. This change cannot be performed in YAM itself, but has to be done with a text editor.

Moved from SF. Original poster: thboeckel

I know about that feature. But I was not thinking about changing the length of the interval, as this would be too much stress. As with an auto-save function this should not be set too small. I was more thinging of YAM handling this a bit more clever, ie. when it knows the content has changed it could update the index. Maybe this could even replace the hard-timed-update. But "for now" it would be nice if at least in some situations YAM could not just sit and wait for the time to pass. I don't see/know the internals of YAM (or any programme), but I wonder, if this would be so/too hard to do a bit more automatic.

Moved from SF. Original poster: padrino

Yes, in principle something like that would be possible of course. However, in practice this would currently severly bring down the performance of YAM in case you have a folder with more than a few thousands mails in it. The problem is, that every mail index write operation takes a few seconds and thus it would halt the whole processing of YAM. This is more or less the reason for the interval-based index saving. Of course we could improve that by either trying to put the index writing into a sub-process which would save the index in the background while normal GUI processing continues. This, however, requires to have the multithreading/processing finalized in YAM. Another possibility would be to change the internal index loading/writing process into a kind of incremental save process so that only the changes to an index would be saved or that YAM would only overwrite the changed portions in the index rather than writing a multiple MB large index all the time.

So there are certainly a few ideas how this index handling could be improved. The main question is, however, if we have the time and manpower to tinker with this now or if there are currently more important things as it take some time to implement that. But thank you for that proposal. Therefore I will keep that Change request open for the time being. But please don't hold your breath until we have addressed it

Moved from SF. Original poster: damato

I'll flag that report for milestone 2.8 because we should have the multithreading functionality until then and can then rethink about how to improve the mail indexing.