Summary
UtilitiesCS/OutlookObjects/Folder/FolderPredictor.cs:691 guards a path-separator check with the
non-short-circuiting bitwise | operator instead of the short-circuiting ||:
olAncestor.EndsWith('\\'.ToString()) | parentBranchPath[0] == '\\'| evaluates both operands unconditionally. The right operand indexes parentBranchPath[0], so
when parentBranchPath is the empty string the expression throws IndexOutOfRangeException before
the guard can take effect - and it does so even when the left operand is already true, which is
exactly the case the author presumably intended to let short-circuit past the index.
The distinction matters because the two operators are visually similar and the compiler accepts both
for bool operands, so this reads as correct at a glance. Replacing | with || does not by itself
make the expression safe for an empty parentBranchPath; it only restores the short-circuit when the
left operand is true. A complete fix must also handle the empty-string case explicitly, for example
by testing parentBranchPath.StartsWith("\\", StringComparison.Ordinal), which is empty-safe, rather
than indexing at all.
Reachability is limited: the defect is not reachable from the Email Filer Controller OK path, and the
asynchronous sibling method at line 752 does not index into the path, so it is unaffected. That
containment is why this is filed separately rather than folded into issue #614. It remains a real
latent crash on any current or future caller that can supply an empty parent branch path, and the
correct fix is small and independently testable.
Found during the issue #614 defect census. It is off the #614 path-representation chain: it does not
contribute to the store-root leak or to a silently-wrong filing destination, so absorbing it into
#614 would widen that fix without cause.
Environment
Steps to Reproduce
- Call
FolderPredictor.CreateFolder with a parentBranchPath of "" and any olAncestor,
including one that ends with a backslash.
- Observe
IndexOutOfRangeException thrown from the guard expression at line 691 rather than the
guard evaluating to true and proceeding.
Expected Behavior
The separator guard evaluates safely for an empty parentBranchPath. When olAncestor already ends
with a backslash, the second operand is not evaluated at all.
Actual Behavior
Both operands are evaluated because | does not short-circuit, and parentBranchPath[0] throws
IndexOutOfRangeException on an empty string.
Logs / Screenshots
Impact / Severity
Latent unhandled exception on a code path that is not currently reachable from the EFC OK path.
Severity is Medium rather than Low because the failure mode is an unhandled exception in path
construction, and the guard's appearance of correctness makes it likely to survive review.
Source
From: docs/features/potential/2026-08-26-folderpredictor-createfolder-non-shortcircuit-or-indexes-empty-path.md
Summary
UtilitiesCS/OutlookObjects/Folder/FolderPredictor.cs:691guards a path-separator check with thenon-short-circuiting bitwise
|operator instead of the short-circuiting||:|evaluates both operands unconditionally. The right operand indexesparentBranchPath[0], sowhen
parentBranchPathis the empty string the expression throwsIndexOutOfRangeExceptionbeforethe guard can take effect - and it does so even when the left operand is already
true, which isexactly the case the author presumably intended to let short-circuit past the index.
The distinction matters because the two operators are visually similar and the compiler accepts both
for
booloperands, so this reads as correct at a glance. Replacing|with||does not by itselfmake the expression safe for an empty
parentBranchPath; it only restores the short-circuit when theleft operand is
true. A complete fix must also handle the empty-string case explicitly, for exampleby testing
parentBranchPath.StartsWith("\\", StringComparison.Ordinal), which is empty-safe, ratherthan indexing at all.
Reachability is limited: the defect is not reachable from the Email Filer Controller OK path, and the
asynchronous sibling method at line 752 does not index into the path, so it is unaffected. That
containment is why this is filed separately rather than folded into issue #614. It remains a real
latent crash on any current or future caller that can supply an empty parent branch path, and the
correct fix is small and independently testable.
Found during the issue #614 defect census. It is off the #614 path-representation chain: it does not
contribute to the store-root leak or to a silently-wrong filing destination, so absorbing it into
#614 would widen that fix without cause.
Environment
c279d40b.Steps to Reproduce
FolderPredictor.CreateFolderwith aparentBranchPathof""and anyolAncestor,including one that ends with a backslash.
IndexOutOfRangeExceptionthrown from the guard expression at line 691 rather than theguard evaluating to
trueand proceeding.Expected Behavior
The separator guard evaluates safely for an empty
parentBranchPath. WhenolAncestoralready endswith a backslash, the second operand is not evaluated at all.
Actual Behavior
Both operands are evaluated because
|does not short-circuit, andparentBranchPath[0]throwsIndexOutOfRangeExceptionon an empty string.Logs / Screenshots
FolderPredictor.cs:691.Impact / Severity
Latent unhandled exception on a code path that is not currently reachable from the EFC OK path.
Severity is Medium rather than Low because the failure mode is an unhandled exception in path
construction, and the guard's appearance of correctness makes it likely to survive review.
Source
From: docs/features/potential/2026-08-26-folderpredictor-createfolder-non-shortcircuit-or-indexes-empty-path.md