<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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>
    <br>
    We really need to decide on a path forward with this issue that is
    compatible with the resources that we have available. My fear is
    that any attempt to code around the existing limitations of a 32 bit
    nsMsgKey value would inevitably introduce regressions that would
    give us years of fun times to look forward to in fixing.<br>
    <br>
    What I propose is that instead of doing this, we just admit that
    local mbox folders are limited in size to 4GB, make sure that any
    usage of mbox folders does not allow >4GB operations, and put our
    efforts instead to finishing the remaining issues in maildir
    support. Bug 793865 would be resolved to WONTFIX. Perhaps this
    represents the existing understanding, and I am just out of touch.<br>
    <br>
    Existing 4GB bugs would be resolved by error reporting, preventing
    operations from occurring if they would cause >4GB operations. <br>
    <br>
    There are a couple of 4GB-related bugs on The List. How they are
    affected:<br>
    <br>
    <table class="bz_buglist sortable" cellpadding="4" cellspacing="0"
      width="100%">
      <tbody class="sorttable_body">
        <tr id="b633093" class="bz_bugitem bz_critical bz_-- bz_NEW
          bz_row_even ">
          <td style="white-space: nowrap" class="bz_cc_count_column"><br>
          </td>
        </tr>
        <tr id="b640371" class="bz_bugitem bz_critical bz_-- bz_NEW
          bz_row_odd ">
          <td class="first-child bz_id_column"> <a
              href="https://bugzilla.mozilla.org/show_bug.cgi?id=640371">640371</a>
          </td>
          <td style="white-space: nowrap" class="bz_bug_severity_column"
            sorttable_customkey="200"> <span title="critical">cri </span>
          </td>
          <td style="white-space: nowrap" class="bz_priority_column"
            sorttable_customkey="100"> <span title="--">-- </span> </td>
          <td style="white-space: nowrap" class="bz_op_sys_column"
            sorttable_customkey="510"> <span title="Windows XP">Wind </span>
          </td>
          <td style="white-space: nowrap" class="bz_assigned_to_column">
            <span title="nobody@mozilla.org"><a class="moz-txt-link-abbreviated" href="mailto:nobody@mozilla.org">nobody@mozilla.org</a> </span>
          </td>
          <td style="white-space: nowrap" class="bz_bug_status_column"
            sorttable_customkey="200"> <span title="NEW">NEW </span> </td>
          <td style="white-space: nowrap" class="bz_resolution_column"
            sorttable_customkey="100"> <span title="---">--- </span> </td>
          <td class="bz_short_desc_column"> <a
              href="https://bugzilla.mozilla.org/show_bug.cgi?id=640371">Local
              Inbox folder allowed to grow past 4GB by mail download </a>
          </td>
          <td style="white-space: nowrap" class="bz_cc_count_column">2 </td>
        </tr>
      </tbody>
    </table>
    <br>
    This would be resolved by making sure that an "Inbox full" message
    occurs rather than dataloss.<br>
    <br>
    <table class="bz_buglist sortable" cellpadding="4" cellspacing="0"
      width="100%">
      <tbody class="sorttable_body">
        <tr id="b673438" class="bz_bugitem bz_critical bz_-- bz_ASSIGNED
          bz_row_even ">
          <td style="white-space: nowrap" class="bz_cc_count_column"><br>
          </td>
        </tr>
        <tr id="b794303" class="bz_bugitem bz_major bz_-- bz_NEW
          bz_row_odd ">
          <td class="first-child bz_id_column"> <a
              href="https://bugzilla.mozilla.org/show_bug.cgi?id=794303">794303</a>
          </td>
          <td style="white-space: nowrap" class="bz_bug_severity_column"
            sorttable_customkey="300"> <span title="major">maj </span>
          </td>
          <td style="white-space: nowrap" class="bz_priority_column"
            sorttable_customkey="100"> <span title="--">-- </span> </td>
          <td style="white-space: nowrap" class="bz_op_sys_column"
            sorttable_customkey="510"> <span title="Windows XP">Wind </span>
          </td>
          <td style="white-space: nowrap" class="bz_assigned_to_column">
            <span title="nobody@mozilla.org"><a class="moz-txt-link-abbreviated" href="mailto:nobody@mozilla.org">nobody@mozilla.org</a> </span>
          </td>
          <td style="white-space: nowrap" class="bz_bug_status_column"
            sorttable_customkey="200"> <span title="NEW">NEW </span> </td>
          <td style="white-space: nowrap" class="bz_resolution_column"
            sorttable_customkey="100"> <span title="---">--- </span> </td>
          <td class="bz_short_desc_column"> <a
              href="https://bugzilla.mozilla.org/show_bug.cgi?id=794303">Compact

              folder fails if local mail folder size is near 4GB(less
              than 4GB) or over 4GB, even though bug 462665 was changed
              to FIXED after patch for bug 402392 was landed on Tb 12.0.
            </a> </td>
          <td style="white-space: nowrap" class="bz_cc_count_column">5 </td>
        </tr>
      </tbody>
    </table>
    <br>
    You should be able to compact any valid mbox folder, so this is a
    valid bug.<br>
    <br>
    :rkent<br>
    <br>
    <br>
  </body>
</html>