<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 1/17/2013 12:59 PM, Kent James
      wrote:<br>
    </div>
    <blockquote cite="mid:50F84A1E.2070809@caspia.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 1/17/2013 7:29 AM, David Bienvenu
        wrote:<br>
      </div>
      <blockquote cite="mid:50F818E2.5070501@davidbienvenu.org"
        type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">On 1/16/2013 2:16 PM, Kent James
          wrote:<br>
        </div>
        <blockquote cite="mid:50F726D4.4070204@caspia.com" type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=UTF-8">
          I was looking today at trying to fix the relatively simple bug
          793865 "<span id="summary_alias_container"><span
              id="short_desc_nonedit_display">nsIMsgParseMailMsgState.envelopePos



              must be 64bits to support large mbox folders"</span></span>,
          figuring that was one needed step on a relatively small path
          to support >4GB mbox files in local folders. But as I
          looked into it, we have never resolved the issue of a 32 bit
          nsMsgKey, which also equals the message offset in local
          folders. It is a far from trivial issue to make progress on
          that.<br>
        </blockquote>
        There's a msg hdr property called something like
        "message-offset" that's used instead of the msgKey as the offset
        into the local folder, by the berkeley mailbox store. The msgKey
        is used for backwards compatibility if there is no
        message-offset. Are you saying the message-offset is never used,
        or sometimes not used?<br>
        <br>
        - David<br>
      </blockquote>
      What I am saying is that the 32 bit nsMsgKey which equals the
      offset in the case of local mbox folders, is still used in way too
      many places as a way to access the particular message in a folder.<br>
      <br>
      If I do an mxr search for nsMsgKey in mail folders, I get "Too
      many hits, displaying the first 1000" I don't understand how the
      application is supposed to work with message-offset as an
      alternative to nsMsgKey in all of those places.<br>
      <br>
      I would love for you to tell me that I am incorrect. But just to
      pick a few examples out of over 1000:<br>
      <br>
      nsIMsgDBView has "selectMsgByKey(in nsMsgKey key)" which is used
      in mailContextMenus.js<br>
      <br>
      nsMsgFilterService has the array m_searchHits which stores search
      hits by their nsMsgKey value<br>
      <br>
      I don't understand how those are supposed to work with a big mbox
      where the offset has exceeded 4GB and the message-offset needs to
      be used instead.<br>
    </blockquote>
    <br>
    nsMsgKey is an opaque 32-bit value that refers to, with a folder, a
    unique message. It has no intrinsic value by itself. The berkeley
    mbox store, if requested to retrieve a message, first looks up the
    message-offset property on a header. If it can't find that property
    (it's a mailbox originally created before this functionality was
    added, say), it falls back on the message key value. So the message
    key isn't necessarily the offset within the mbox file; it can just
    as well be a 32-bit counter that starts at 0 and increments by 1
    every time a new message arrives.<br>
    <pre class="moz-signature" cols="72">-- 
Joshua Cranmer
News submodule owner
DXR coauthor</pre>
  </body>
</html>