Document how Mork filehandles are managed.
Categories
(MailNews Core :: Database, task)
Tracking
(Not tracked)
People
(Reporter: benc, Unassigned)
References
(Blocks 1 open bug)
Details
There are a lot of places in the code which seem to perform all kinds of voodoo to try and influence when .msf files are opened and closed.
For example, there are a load of places where code will null out the .msgDatabase attribute. Presumably, a bunch of these rely on the msgDB object being destroyed and the underlying filehandle being closed... (if it's open).
I think the underlying rationale is that there are installs out there which have huge numbers of folders, each with their own msgDB (.msf file), and running into filehandle limits can be an issue on some OSes...
But it's really unclear when the actual files are opened and closed. It's all obfuscated by layers of mork code, then layers of nsMsgDatabase on top of that (and folder code on top of that).
So. In order to replace mork, we'll need to know exactly how the file handles are managed, in order to understand what these little voodoo hacks are trying to achieve.
|
||
Comment 1•5 months ago
|
||
Agreed.
At least, if we can document the upper layer of mork DB operation, i.e., what C-C TB does using mork at the highly abstract level, it may help us to move to SQLITE3, etc.
Description
•