proton-mail-bridge-client 2.0.0 → 2.0.2

package/dist/services/simple-imap-service.js

@@ -1,5 +1,5 @@
 import { realpathSync } from "node:fs";
-import { mkdir, stat, writeFile } from "node:fs/promises";
+import { mkdir, open, stat, writeFile } from "node:fs/promises";
 import { basename, dirname, join, resolve, sep } from "node:path";
 import { ImapFlow } from "imapflow";
 import { simpleParser } from "mailparser";
@@ -225,6 +225,10 @@ export function planFolderSync(input) {
             strategy: "empty",
             changed: false,
             highestKnownUid,
+            // Only a genuine server-reported exists === 0 means the mailbox is
+            // actually empty — highestKnownUid === 0 alone (uidNext missing/1)
+            // isn't proof of that, so it must not trigger index cleanup on its own.
+            folderObservedEmpty: input.exists === 0,
         };
     }
     if (input.full) {
@@ -238,12 +242,29 @@ export function planFolderSync(input) {
         const uidValidityMatches = !input.checkpoint?.uidValidity || !input.uidValidity || input.checkpoint.uidValidity === input.uidValidity;
         const priorFloor = uidValidityMatches ? input.checkpoint?.backfilledToUid : undefined;
         if (priorFloor !== undefined && priorFloor <= 1) {
-            // Already backfilled all the way back to UID 1 in a previous call —
-            // nothing older left to fetch.
+            // Already backfilled all the way back to UID 1 in a previous call.
+            // History is fully covered, but full:true must still surface mail
+            // that arrived *after* backfill completed — otherwise, once a folder
+            // finishes backfilling, full:true silently stops discovering any new
+            // mail forever, even as highestKnownUid keeps growing. Top up with a
+            // bounded fetch of just the newly-arrived range.
+            const priorHighest = input.checkpoint?.highestUid ?? 0;
+            if (highestKnownUid <= priorHighest) {
+                return {
+                    folder: input.folder,
+                    strategy: "full",
+                    changed: false,
+                    highestKnownUid,
+                    backfilledToUid: priorFloor,
+                };
+            }
+            const topUpStart = Math.max(1, priorHighest + 1, highestKnownUid - input.limit + 1);
             return {
                 folder: input.folder,
                 strategy: "full",
-                changed: false,
+                changed: true,
+                startUid: topUpStart,
+                endUid: highestKnownUid,
                 highestKnownUid,
                 backfilledToUid: priorFloor,
             };
@@ -283,16 +304,46 @@ export function planFolderSync(input) {
         };
     }
     const overlap = Math.min(input.limit, Math.max(25, Math.min(100, Math.ceil(input.limit / 2))));
-    const changed = highestKnownUid > (input.checkpoint.highestUid ?? 0) ||
-        uidNext !== (input.checkpoint.uidNext ?? uidNext) ||
-        input.exists !== (input.checkpoint.total ?? input.exists);
+    const knownHighUid = input.checkpoint.highestUid ?? 0;
+    // Undefined (not stored as null-ish 0) means "no catch-up in progress" — see the
+    // backfilledToUid comment above for why this codebase maps SQLite NULL to
+    // undefined rather than null for exactly this kind of cursor field.
+    const resumeUid = input.checkpoint.incrementalResumeUid;
+    if (resumeUid === undefined && highestKnownUid - knownHighUid <= input.limit) {
+        // Fully caught up (or the gap is small enough to close in one call): the
+        // established incremental behavior — re-fetch a small overlap window to catch
+        // flag changes on already-seen messages, then fetch forward to the true top.
+        const changed = highestKnownUid > knownHighUid ||
+            uidNext !== (input.checkpoint.uidNext ?? uidNext) ||
+            input.exists !== (input.checkpoint.total ?? input.exists);
+        return {
+            folder: input.folder,
+            strategy: changed ? "incremental" : "incremental_window",
+            changed,
+            startUid: Math.max(1, Math.min(highestKnownUid, knownHighUid) - overlap + 1),
+            endUid: highestKnownUid,
+            highestKnownUid,
+        };
+    }
+    // The gap between the checkpoint and the mailbox's current top UID is larger than
+    // `limit` — e.g. after a long time offline or a large mail import. Previously this
+    // branch fetched startUid:highestKnownUid unconditionally, so `limit` only ever
+    // shrank the overlap, never bounded the actual range: a checkpoint at UID 1000 with
+    // the server at UID 100000 could plan a 976:100000 fetch — ~99k messages parsed and
+    // held in memory in one call regardless of `limit`. Fetch one limit-sized bounded
+    // slice instead, and persist how far it reached as incrementalResumeUid so the next
+    // call continues forward from there rather than re-planning the whole remaining gap.
+    const startUid = resumeUid !== undefined ? resumeUid + 1 : Math.max(1, knownHighUid - overlap + 1);
+    const endUid = Math.min(highestKnownUid, startUid + input.limit - 1);
+    const reachesTop = endUid === highestKnownUid;
     return {
         folder: input.folder,
-        strategy: changed ? "incremental" : "incremental_window",
-        changed,
-        startUid: Math.max(1, Math.min(highestKnownUid, input.checkpoint.highestUid) - overlap + 1),
-        endUid: highestKnownUid,
+        strategy: "incremental",
+        changed: true,
+        startUid,
+        endUid,
         highestKnownUid,
+        incrementalResumeUid: reachesTop ? undefined : endUid,
     };
 }
 function mapFolder(entry) {
@@ -876,8 +927,24 @@ export class SimpleIMAPService {
                 }
             }
             else {
-                const endSeq = total - offset;
-                const startSeq = Math.max(1, endSeq - limit + 1);
+                // Found on review: sortByUid only sorted the fetched page afterward
+                // (below) — the *range itself* was always anchored to the newest
+                // end regardless of direction, so "asc" (oldest first) paginated
+                // through progressively OLDER newest-end windows (91-100, then
+                // 81-90) instead of walking forward from the true oldest message
+                // (1-10, then 11-20), contradicting the documented "oldest first"
+                // behavior and never reaching a stable, monotonically-advancing
+                // cursor across pages.
+                let startSeq;
+                let endSeq;
+                if (input.sortByUid === "asc") {
+                    startSeq = offset + 1;
+                    endSeq = Math.min(total, startSeq + limit - 1);
+                }
+                else {
+                    endSeq = total - offset;
+                    startSeq = Math.max(1, endSeq - limit + 1);
+                }
                 for await (const message of client.fetch(`${startSeq}:${endSeq}`, fetchQuery)) {
                     const summary = this.toSummary(folder, message);
                     const enriched = input.includeSnippet && message.source
@@ -1450,6 +1517,17 @@ export class SimpleIMAPService {
         this.folderCache = undefined;
         return { folder, deleted: uids.length };
     }
+    // Not private: index.ts's bulk_delete/bulk_update_flags/bulk_update_labels
+    // handlers call this directly to resolve a match/emailIds set exactly
+    // once, then pass the result back in as `resolvedUids` so the dryRun and
+    // real-run calls act on the identical set instead of each re-resolving
+    // `match` against the live mailbox. See resolvedUids below for why: two
+    // separate resolutions of the same `match` can return different UID sets
+    // if the mailbox changes between them (e.g. new mail arrives), letting a
+    // bulk op exceed its configured maxBatchSize. Found live: with
+    // maxBatchSize 1, a first resolution returned [1], a second (between the
+    // dry-run check and the real run) returned [1,2], and the real run acted
+    // on both — silently exceeding the limit.
     async resolveUidsForBulkOp(folder, emailIds, match) {
         if (emailIds !== undefined && match !== undefined) {
             throw new Error("Provide either emailIds or match, not both");
@@ -1585,7 +1663,7 @@ export class SimpleIMAPService {
     }
     async bulkDelete(input) {
         const folder = input.folder?.trim() || "INBOX";
-        const uids = await this.resolveUidsForBulkOp(folder, input.emailIds, input.match);
+        const uids = input.resolvedUids ?? await this.resolveUidsForBulkOp(folder, input.emailIds, input.match);
         if (input.dryRun) {
             return {
                 dryRun: true,
@@ -1670,7 +1748,7 @@ export class SimpleIMAPService {
     }
     async bulkUpdateFlags(input) {
         const folder = input.folder?.trim() || "INBOX";
-        const uids = await this.resolveUidsForBulkOp(folder, input.emailIds, input.match);
+        const uids = input.resolvedUids ?? await this.resolveUidsForBulkOp(folder, input.emailIds, input.match);
         if (input.dryRun) {
             return {
                 dryRun: true,
@@ -1743,7 +1821,7 @@ export class SimpleIMAPService {
     }
     async bulkUpdateLabels(input) {
         const folder = input.folder?.trim() || "INBOX";
-        const uids = await this.resolveUidsForBulkOp(folder, input.emailIds, input.match);
+        const uids = input.resolvedUids ?? await this.resolveUidsForBulkOp(folder, input.emailIds, input.match);
         if (input.dryRun) {
             return {
                 dryRun: true,
@@ -2072,6 +2150,8 @@ export class SimpleIMAPService {
                         fetched: 0,
                         total: exists,
                         backfilledToUid: plan.backfilledToUid,
+                        folderObservedEmpty: plan.folderObservedEmpty,
+                        incrementalResumeUid: plan.incrementalResumeUid,
                     },
                     emails: [],
                 };
@@ -2100,7 +2180,10 @@ export class SimpleIMAPService {
             // unchanged; using this batch's (much lower) fetched UIDs here would
             // silently roll the incremental-sync high-water-mark backward and
             // make every subsequent incremental sync think a huge amount of
-            // "new" mail exists again.
+            // "new" mail exists again. The same reasoning applies to a bounded
+            // incremental catch-up window (large gap since the last checkpoint):
+            // its endUid is also below highestKnownUid until the last batch closes
+            // the gap.
             const reachesTop = plan.endUid === plan.highestKnownUid;
             const highestUid = reachesTop
                 ? emails.reduce((max, email) => Math.max(max, email.uid), 0) || plan.highestKnownUid
@@ -2122,6 +2205,7 @@ export class SimpleIMAPService {
                     rangeStartUid: plan.startUid,
                     rangeEndUid: plan.endUid,
                     backfilledToUid: plan.backfilledToUid,
+                    incrementalResumeUid: plan.incrementalResumeUid,
                 },
                 emails,
             };
@@ -2761,11 +2845,30 @@ export class SimpleIMAPService {
         }
     }
     async writeAttachmentToPath(emailId, attachment, outputPath) {
-        const outputFilePath = await this.resolveAttachmentOutputPath(emailId, attachment, outputPath);
-        // 0o700/0o600: this writes the user's own private email content — restrict
-        // it to the owner regardless of the destination directory's own permissions.
-        await mkdir(dirname(outputFilePath), { recursive: true, mode: 0o700 });
-        await writeFile(outputFilePath, attachment.content, { mode: 0o600 });
+        let outputFilePath;
+        if (!outputPath) {
+            // No caller-supplied outputPath: attachments land in a shared default
+            // per-message directory keyed only by their own (sanitized) filename,
+            // so two attachments sharing a name — in this batch, or left over from
+            // a prior save — must never silently clobber each other. Resolve the
+            // final on-disk name via atomic exclusive-create instead of the
+            // explicit-outputPath branch below, which already gets its uniqueness
+            // and containment guarantees from the caller (saveAttachments' usedPaths
+            // dedup) and guardAttachmentOutputPath.
+            const filename = sanitizeFileName(attachment.filename, attachment.id || "attachment");
+            const dirPath = join(this.config.dataDir, "attachments", encodeURIComponent(emailId));
+            // 0o700/0o600: this writes the user's own private email content — restrict
+            // it to the owner regardless of the destination directory's own permissions.
+            await mkdir(dirPath, { recursive: true, mode: 0o700 });
+            outputFilePath = await this.writeAttachmentUnique(dirPath, filename, attachment.content);
+        }
+        else {
+            outputFilePath = await this.resolveAttachmentOutputPath(emailId, attachment, outputPath);
+            // 0o700/0o600: this writes the user's own private email content — restrict
+            // it to the owner regardless of the destination directory's own permissions.
+            await mkdir(dirname(outputFilePath), { recursive: true, mode: 0o700 });
+            await writeFile(outputFilePath, attachment.content, { mode: 0o600 });
+        }
         return {
             emailId,
             attachment: {
@@ -2784,6 +2887,43 @@ export class SimpleIMAPService {
             outputPath: basename(outputFilePath),
         };
     }
+    // Writes `content` under dirPath as `filename`, guaranteeing the result
+    // never silently overwrites an existing file — whether that file is another
+    // attachment from the same save() call or one left over from a prior save.
+    // Uses open(..., "wx") (atomic exclusive-create, same primitive
+    // file-lock.ts uses for its own lock files) rather than existsSync() +
+    // writeFile(), so a second concurrent save can't interleave between the
+    // check and the write. On a collision, retries with a numeric suffix before
+    // the extension (report.txt → report (1).txt → report (2).txt → ...),
+    // matching the convention saveAttachments already uses for its
+    // explicit-outputPath batch dedup.
+    async writeAttachmentUnique(dirPath, filename, content) {
+        const ext = filename.includes(".") ? filename.slice(filename.lastIndexOf(".")) : "";
+        const stem = filename.slice(0, filename.length - ext.length);
+        let candidateName = filename;
+        let counter = 0;
+        for (;;) {
+            const candidatePath = join(dirPath, candidateName);
+            try {
+                const handle = await open(candidatePath, "wx", 0o600);
+                try {
+                    await handle.writeFile(content);
+                }
+                finally {
+                    await handle.close();
+                }
+                return candidatePath;
+            }
+            catch (error) {
+                if (error && typeof error === "object" && "code" in error && error.code === "EEXIST") {
+                    counter += 1;
+                    candidateName = `${stem} (${counter})${ext}`;
+                    continue;
+                }
+                throw error;
+            }
+        }
+    }
     // Returns the validated real path so callers write through the same
     // resolved path they just checked, instead of re-deriving it — re-deriving
     // left a TOCTOU window where a symlink swapped in between validation and
@@ -2817,7 +2957,7 @@ export class SimpleIMAPService {
                 throw error;
             }
         }
-        if (!targetRealPath.startsWith(`${allowedRealPath}/`) && targetRealPath !== allowedRealPath) {
+        if (!targetRealPath.startsWith(`${allowedRealPath}${sep}`) && targetRealPath !== allowedRealPath) {
             throw new Error("outputPath path escapes the allowed directory.");
         }
         return targetRealPath;