Bugzilla

See comment 200 for more details.
I don't know that this is the best fix for the problem but it does work. The problem is that with default "retention setting", where all messages are retained and none are purged on the default 8 hr interval, there appears in folderCache.json (a.k.a. cache file) for each folder an element ```"LastPurgeTime" : null,". When this is read on the purge interval an error occurs when read from folderCache.json and then an attempt is made to read it from the folder's database file. This ends up possibly opening many folders when the user has a lot of folders -- sometimes more than the OS limit, e.g., 512 for windows. This causes the database file (e.g., folder.msf) to be deleted and then causes re-downloads.

So rather than trying to open the DB when LastPurgeTime fails to read from cache, the patch just goes ahead and allows the purge process to continue and attempt the purge (if folder not using default retention settings) which sets a valid time string into cache for LastPurgeTime so on subsequent intervals LastPurgeTime is successfully read from cache  and the DB does not need to be opened to read LastPurgeTime.

I think maybe a better fix would be to set the initial value of LastPurgeTime in the cache to the current time. However, I haven't been able to find where or how the initial value of LastPurgeTime is set to null in FolderCache.json.  Also, FWIW, on initial creation of FolderCache.json, LastPurgeTime is not present at all and only appears a few minutes later with a null value. It appears to originate from the DB file (folder.msf) but I also can't see how that happens.

See comment 200 for more details.
I don't know that this is the best fix for the problem but it does work. The problem is that with default "retention setting", where all messages are retained and none are purged on the default 8 hr interval, there appears in folderCache.json (a.k.a. cache file) for each folder an element ```"LastPurgeTime" : null,```. When this is read on the purge polling interval (default 5 min.) an error occurs when read from folderCache.json and then an attempt is made to read it from the folder's database file. This ends up possibly opening many folders when the user has a lot of folders -- sometimes more than the OS limit, e.g., 512 for windows. This causes the database file (e.g., folder.msf) to be deleted and then causes re-downloads.

So rather than trying to open the DB file when LastPurgeTime fails to read from cache, the patch just goes ahead and allows the purge process to continue and attempt the purge (if folder not using default retention settings) which sets a valid time string into cache file for LastPurgeTime so on subsequent intervals LastPurgeTime is successfully read from cache  and the DB does not need to be opened to read LastPurgeTime.

I think maybe a better fix would be to set the initial value of LastPurgeTime in the cache to the current time. However, I haven't been able to find where or how the initial value of LastPurgeTime is set to null in FolderCache.json.  Also, FWIW, on initial creation of FolderCache.json, LastPurgeTime is not present at all for all folders and only appears a few minutes later with a null value. It seems to somehow originate from the DB file (folder.msf) but I also can't find how that happens.