Bug: efc-store-root-selection-leaks-full-outlook-path-into-filing-boundary

[drmoisan]

• Work Mode: full-bug

Summary

Filing an email from the Email Filer Controller (EFC) throws ArgumentException from
FolderConverter.ToFsFolderpath because a full Outlook hierarchy path (the mailbox store root,
e.g. \\mailbox@example.com) reaches EmailFilerConfig.DestinationOlStem, which by contract must
be an archive-relative stem. The reported "illegal character" (the . in the mailbox address) is a
downstream symptom of a path-representation contract that is enforced at no boundary; the true
defect set spans breadcrumb hierarchy selection, archive-root resolution, special-folder
resolution, and the Outlook-path-to-filesystem-path converter itself.

Environment

• OS/version: Windows 11 Pro 10.0.26200; Outlook desktop with a Microsoft 365 mailbox whose store
  display name is the account email address.
• Python version: Not applicable; the affected implementation and tests are C# (.NET Framework
  4.8.1 VSTO add-in).
• Command/flags used: Not applicable; reached interactively through the EFC folder-list breadcrumb
  surface and the OK button.
• Data source or fixture: Archive root \\mailbox@example.com\Archive; OneDrive commercial root
  C:\Users\<user>\OneDrive - <Org>.

Steps to Reproduce

1. Open the QuickFiler EFC surface against a mailbox whose store root path is
   \\mailbox@example.com and whose archive root is \\mailbox@example.com\Archive.
2. Bind folder rows so that a breadcrumb row renders its ancestor chain
   (IFolderHierarchyProvider.GetAncestorChainAsync, which is requested with
   FolderTreeRequest.AllStores and therefore walks all the way up to the store root).
3. Activate an ancestor segment at or above the archive root. In the observed case this was the
   store-root segment itself.
4. Press OK to execute the move.

Expected Behavior

Either the segment at or above the archive root is not selectable as a filing destination, or the
selection is clamped or rejected before it reaches the filing boundary. Every value that flows into
EfcDataModel.MoveToFolderAsync and EmailFilerConfig.DestinationOlStem remains an
archive-relative stem (for example Clients\North), and FolderConverter.ToFsFolderpath validates
only the segments it derives, never the caller-supplied filesystem ancestor root, which
legitimately contains ., spaces and -.

Actual Behavior

ArgumentException is thrown and the move fails:

System.ArgumentException: fsPathExDividers has a value of
Users<user>OneDrive - <Org>mailbox@example.com which contains illegal characters .
Parameter name: fsPath
   at UtilitiesCS.FolderConverter.ToFsFolderpath(String olBranchPath, String olAncestorPath, String fsAncestorEquivalent, Boolean ask) in UtilitiesCS\OutlookObjects\Folder\FolderConverter.cs:line 169
   at UtilitiesCS.EmailIntelligence.EmailParsingSorting.EmailFilerConfig.ResolvePaths(Folder currentFolder) in UtilitiesCS\EmailIntelligence\EmailParsingSorting\EmailFilerConfig.cs:line 188
   at UtilitiesCS.EmailIntelligence.EmailParsingSorting.EmailFiler.ResolvePaths(Folder currentFolder) in UtilitiesCS\EmailIntelligence\EmailParsingSorting\EmailFiler.cs:line 378
   at UtilitiesCS.EmailIntelligence.EmailParsingSorting.EmailFiler.SortAsync(...) in UtilitiesCS\EmailIntelligence\EmailParsingSorting\EmailFiler.cs:line 133
   at QuickFiler.Controllers.EfcDataModel.MoveToFolderAsync(...) in QuickFiler\Controllers\EfcDataModel.cs:line 293
   at QuickFiler.EfcHomeController.ExecuteMovesCoreAsync() in QuickFiler\Controllers\EfcHomeController.ExecuteMoves.cs:line 75
   at QuickFiler.EfcHomeController.ExecuteMovesAsync() in QuickFiler\Controllers\EfcHomeController.ExecuteMoves.cs:line 40
   at QuickFiler.Controllers.EfcFormController.ActionOkAsync() in QuickFiler\Controllers\EfcFormController.cs:line 716
   at QuickFiler.Controllers.EfcFormController.ButtonOK_Click(...) in QuickFiler\Controllers\EfcFormController.cs:line 441

Algebraic reconstruction of the reported message. This is the evidence that the stem, not the
character class, is the defect. ToFsFolderpath strips the first three characters (C:\) and then
removes every \, so the reported value implies:

fsPath == "C:\Users\<user>\OneDrive - <Org>" + "\" + "\\mailbox@example.com"

Working backwards through EmailFilerConfig.ResolvePaths:

DestinationOlPath = OlAncestor + "\" + DestinationOlStem
fsPath            = DestinationOlPath.Replace(OlAncestor, FsAncestorEquivalent)

With OlAncestor = \\mailbox@example.com\Archive and
FsAncestorEquivalent = C:\Users\<user>\OneDrive - <Org>, the only stem that reproduces the
reported string exactly is DestinationOlStem == "\\mailbox@example.com", that is, the mailbox
store root carried through as a full Outlook path. No stem containing a real destination folder
name reproduces the message, because the message ends immediately after the mailbox address.

Logs / Screenshots

• Attached minimal logs or screenshot
• Snippet: the exception and stack shown above, captured at the throw site.

Impact / Severity

• Blocker
• High
• Medium
• Low

Filing fails outright for the affected selection path, and adjacent defects in the same chain can
silently produce a wrong destination rather than an exception.

Source

From: docs/features/potential/2026-08-26-efc-store-root-selection-leaks-full-outlook-path-into-filing-boundary.md

[drmoisan]

Suspected Cause / Notes

The Copilot hypothesis, "remove . from IllegalFolderCharacters", addresses the symptom only.
Removing . would let the call succeed while still filing to a destination derived from the
mailbox store root. The candidate defect set below must be confirmed or refuted by investigation;
it is a starting hypothesis set, not a verified list.

1. QuickFiler/Controllers/BreadcrumbBridgeRouter.cs ToArchiveRelativePath(fullPath): when
   fullPath is not at or under _archiveRootPath, the method returns the full path verbatim.
   That value is assigned to SelectedFolderPath, surfaces as EfcFormController.SelectedFolder,
   and is handed to EfcDataModel.MoveToFolderAsync as an archive-relative stem. There is no
   rejection, no clamp and no diagnostic.
2. BreadcrumbBridgeRouter.ActivateSegment and ActivateChild call
   SelectHierarchyPath(row, segment.FullPath) for any segment in the chain. The chain comes from
   OutlookFolderHierarchyProvider.GetAncestorChainAsync, which acquires
   FolderTreeRequest.AllStores(allowStaleSnapshot: true) and walks to the store root. Segments at
   or above the archive root, and segments belonging to a different store entirely, are therefore
   selectable as filing destinations.
3. BreadcrumbBridgeRouter.ToHierarchyPath is the mirror-image hazard: a presented target that is
   an absolute path outside the archive root is prefixed with the archive root, producing a
   nonexistent hierarchy path.
4. UtilitiesCS/EmailIntelligence/EmailParsingSorting/EmailFilerConfig.cs ResolvePaths and
   ResolvePaths(Folder) concatenate OlAncestor + "\" + DestinationOlStem with no validation that
   the stem is relative. Issue Bug: efc-full-path-destination-resolution-regression #609 (closed, PR Preserve archive-relative Efc filing destinations #611) established this boundary but addressed only
   the "stem already carries the archive root prefix" case, not "stem is an unrelated absolute
   path". The stem contract is documented in prose and enforced nowhere.
5. UtilitiesCS/OutlookObjects/Folder/FolderConverter.cs ToFsFolderpath carries several
   independent defects:
   • It validates the entire concatenated path, including the caller-supplied
     fsAncestorEquivalent, instead of only the segments it derives. Any legitimate OneDrive
     commercial root containing ., [ or ] fails regardless of the stem.
   • IllegalFolderCharacters ([\/:*?"<>|].) is wrong in both directions: ., [ and ] are
     legal in Windows names, while the control characters in Path.GetInvalidFileNameChars() are
     absent. The real Windows rules it should encode are per-segment: invalid characters, trailing
     dot or space, and reserved device names.
   • fsPath.Substring(3) assumes a rooted X:\ path and will throw or silently mangle a UNC or
     relative fsAncestorEquivalent.
   • olBranchPath.Replace(olAncestorPath, fsAncestorEquivalent) is an unanchored, case-sensitive
     replace-all. It should be a prefix-anchored OrdinalIgnoreCase strip; today a repeated
     ancestor substring is replaced at every occurrence.
   • The exception message embeds the full user-profile path and mailbox address, the runtime
     counterpart of issue Repository-wide host-identifier leakage: absolute user-profile paths, account and host names in tracked files #602.
   • BuildAlternativesDictionary's "Remove illegal characters" option evaluates
     illegalFolderName.Replace(illegalFolderName, ""), which always returns the empty string.
   • ResolveOlRoot selects the root with Contains rather than a prefix test, so it can return
     the wrong ancestor when one root path is a substring of the other.
6. TaskMaster/AppGlobals/AppOlObjects.cs ArchiveRootPath is
   Path.Combine(Root.FolderPath, "Archive") over App.Session.DefaultStore. It is neither
   verified to exist nor scoped to the store that owns the current folder, so with multiple stores
   the ancestor never matches and every downstream Replace or StartsWith silently no-ops.
7. TaskMaster/AppGlobals/AppFileSystemFolderPaths.cs LoadFolders falls back for the OneDrive
   key to AppData and finally to SpecialFolders.First().Value, an arbitrary dictionary entry. A
   wrong FsAncestorEquivalent is accepted silently. MatchBestSpecialFolder also matches with
   Contains rather than a path-prefix test.
8. QuickFiler/Controllers/EfcDataModel.cs MoveToFolderAsync(MAPIFolder, olAncestor, ...) strips
   exactly one leading backslash (Substring(1)), so a store-root path beginning with \\ retains
   a leading separator, and its Replace(olAncestor, "") is likewise unanchored.

Proposed Fix / Validation Ideas

• Introduce and enforce an explicit path-representation contract that separates a full Outlook
  hierarchy path from an archive-relative stem, validated at the filing boundary rather than
  documented in prose.
• Clamp or reject breadcrumb selections at or above the archive root, and selections outside the
  archive's store, with a deterministic diagnostic instead of a silent pass-through.
• Replace the hand-rolled IllegalFolderCharacters check with per-segment Windows name
  validation, scoped to derived segments only and never to the caller-supplied filesystem root.
• Make ToFsFolderpath prefix-anchored and case-insensitive, remove the Substring(3)
  assumption, and redact host identifiers from its exception messages.
• Validate ArchiveRootPath and the OneDrive special folder at resolution time; fail
  explicitly rather than falling back to an arbitrary special folder.
• Unit coverage areas: BreadcrumbBridgeRouter (store-root segment activation, cross-store
  segment activation, ancestor-at-archive-root activation, child activation), EmailFilerConfig
  (absolute-stem rejection, single-prefix construction), FolderConverter (dotted and bracketed
  filesystem roots, UNC roots, repeated ancestor substring, per-segment illegal characters,
  trailing dot or space, reserved names), AppFileSystemFolderPaths.MatchBestSpecialFolder
  (prefix versus Contains), EfcDataModel (double-backslash store-root stripping).
• Integration scenario to retest: the issue Bug: efc-full-path-destination-resolution-regression #609 scenarios (direct row selection, ancestor
  activation, child activation, banner and trash pseudo-rows) must retain their current
  behavior.
• Manual verification notes: file to a normal archive subfolder, then attempt the store-root
  ancestor selection and confirm the new deterministic behavior.
• Coordinate with open issue Bug: breadcrumb-router-stale-selectedfolderpath-after-rebind #499 (breadcrumb-router-stale-selectedfolderpath-after-rebind),
  which touches the same SelectedFolderPath field; do not silently absorb or regress it.

[drmoisan]

Outcome (2026-08-26)

Implemented. All nine confirmed defects D1 through D9 are fixed and all 26 acceptance criteria
are verified and checked off in spec.md.

The common root cause was four independent, unanchored ancestor-strip implementations with no
boundary enforcing that a filing stem is archive-relative. They are all now backed by one
authority, UtilitiesCS/OutlookObjects/Folder/ArchiveStemContract.cs, whose match is
prefix-anchored, ordinal case-insensitive, and separator-terminated, and which never passes its
input through on failure.

Where each defect was fixed:

• D1, D2, D3 - QuickFiler/Controllers/BreadcrumbBridgeRouter.cs. Activating a segment outside
  the bound archive root, or the archive root itself, is now a deterministic non-selection; the
  prior selection is left unchanged and is never set to null. SelectRow rejects an out-of-root
  full Outlook filing target, and ToHierarchyPath no longer fabricates an out-of-root hierarchy
  path.
• D4 - UtilitiesCS/EmailIntelligence/EmailParsingSorting/EmailFilerConfig.cs. Both
  ResolvePaths overloads reject a non-relative DestinationOlStem BEFORE concatenation. This is
  the boundary whose absence produced the reported crash.
• D5a-D5g - UtilitiesCS/OutlookObjects/Folder/FolderConverter.cs. Per-segment Windows
  folder-name validation applied only to derived segments; the Substring(3) drive-prefix
  assumption removed; the ancestor strip anchored; the exception message redacted; the "Remove
  illegal characters" option fixed to remove only illegal characters; ResolveOlRoot anchored; and
  the never-read bool ask = true parameter removed.
• D6 - TaskMaster/AppGlobals/AppOlObjects.cs plus the new pure
  TaskMaster/AppGlobals/ArchiveRootPathGuard.cs. ArchiveRootPath is cross-checked once, at
  resolution time, against the folder that actually resolves for it.
• D7 - TaskMaster/AppGlobals/AppFileSystemFolderPaths.cs. The OneDrive root resolves in
  priority order through an injectable environment-read seam and fails explicitly instead of
  falling back to AppData or to an arbitrary first entry.
• D8 - QuickFiler/Controllers/EfcDataModel.cs. The new pure ToArchiveRelativeStem helper
  replaces the unanchored Replace plus single Substring(1).
• D9 - the new QuickFiler/Controllers/EfcSelectionGuard.cs. ActionOkAsync and
  IsValidSelection now share one predicate that also rejects any full Outlook path.

Rejected hypothesis: removing . from IllegalFolderCharacters is NOT the fix. It would remove
the exception without removing the leak, converting a loud crash into silent misfiling. The
character class is corrected, but only behind the new stem guard.

Every production message, log line, and exception message added by this change names the violated
rule only and withholds the path value, which can carry a mailbox address or a user-profile path
(open issue #602).

Two deliberate, documented spec corrections were required because two existing tests codified
defects as expected behaviour. Both are recorded in full in change-description.2026-08-26.md:
FolderConverterTests.cs:329 (D5f) and
Issue439ArchiveRootBoundarySelectionAndHostEventRemainDeterministic (D1/D9). The latter is a
user-visible behaviour change: #439 deliberately permitted selecting a verified hierarchy path
outside the archive root, and #614 intentionally revokes that for the filing surface.

Verification (single clean toolchain pass, restart count 3):

Gate	Result
dotnet tool run csharpier check .	EXIT 0; 0 of 4732 hashed source files rewritten by the format pass
analyzer /t:Rebuild	EXIT 0; 0 errors; 18 projects recompiled
nullable /t:Rebuild (CI-identical, no /p:Nullable=enable)	EXIT 0; 0 errors; 0 CS86xx
full suite with coverage	EXIT 0; 6569 total, 6569 passed, 0 failed, 0 skipped (baseline 6482/6482/0)
filtered first-party line coverage	84.8696%, up from the 84.7797% merge-base baseline
new-code line coverage	100% on ArchiveStemContract, EfcSelectionGuard, ArchiveRootPathGuard, and every changed method

Open issue #499 remains open and unregressed: this change does not touch BindRowsAsync's
selection-clearing semantics, and it leaves SelectedFolderPath unchanged rather than null on
rejection.

Two items are flagged for maintainer review:

1. Manual validation not executed. The five live-Outlook steps in the spec's Test Strategy are
   each recorded as NOT EXECUTED with reason: an automated agent session has no interactive Outlook
   profile, and live-Outlook interaction is excluded from automated tests by policy. Each step has a
   headless automated counterpart that passed; see
   evidence/qa-gates/manual-validation.2026-08-26T18-55.md.
2. One path outside the plan's enumerated in-scope list was modified:
   QuickFiler.Test/packages.config, a single added line pinning log4net 3.3.2 - the version the
   rest of the solution already pins. It is the mechanically necessary companion of the allowlisted
   QuickFiler.Test.csproj reference addition, which was itself required to make AC2's and AC3's
   "emits a diagnostic" assertion testable through the repository's established MemoryAppender
   pattern. Full justification is in evidence/qa-gates/p8-t2-scope-audit.2026-08-26T18-40.md.

One pre-existing condition was observed and recorded rather than changed:
UtilitiesCS.Test/OutlookExtensions/FolderConverter_Tests.cs exists on disk but carries no
<Compile Include> item, so it is not compiled into UtilitiesCS.Test.dll. Its single test
duplicates a compiled, green assertion. Recorded in
evidence/regression-testing/p5-t7-converter-tests.2026-08-26T17-45.md for follow-up triage.