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•1 year 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.
|
||
Comment 2•7 months ago
|
||
(In reply to Ben Campbell from comment #0)
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...
I don't recall ever seeing the exact reason - I'm inclined to think it originates to old hardware days's physical+virtual memory capacity.
But filehandle limits is a real thing. Two examples:
- Bug 495911 - "Unable to load address book file abook.mab. It may be read-only, or locked by another application. Please try again later." Possibly caused by too many file handles in use.
- Bug 855751 - TB forgetting folder view and display prefs after running out of file handles on Mac. (also on linux with similar config) "The file XXXX could not be opened. ..."
Mac users who have lots of fonts (design people for example) can get into trouble ala Bug 701661 - Firefox maintain an open file descriptor for every single font
Description
•