Skip to content

fix: preserve nested scheduled-import paths on case-insensitive Windows roots#583

Open
chuenchen309 wants to merge 1 commit into
nashsu:mainfrom
chuenchen309:fix/scheduled-import-windows-case-insensitive
Open

fix: preserve nested scheduled-import paths on case-insensitive Windows roots#583
chuenchen309 wants to merge 1 commit into
nashsu:mainfrom
chuenchen309:fix/scheduled-import-windows-case-insensitive

Conversation

@chuenchen309

Copy link
Copy Markdown
Contributor

Why

scheduledImportDestinationForFile()'s containment check compares source === importRoot / source.startsWith(importRoot + "/") case-sensitively, but Windows drive-letter and UNC paths are case-insensitive. When a source file's casing differs from the configured import root (e.g. root C:/Users/Me/Inbox, source c:/users/me/inbox/sub/report.pdf), the containment check fails and the file falls back to file.name only — silently flattening its nested directory structure and risking same-name collisions from different folders.

What

Reuse the existing drive-letter/UNC case-folding logic already used by dbDirectoryKey (extracted into a shared caseFoldPath helper) for the containment comparison only. The returned destination path still uses the source file's original casing.

Note: distinct from #582 (also open, same file) — that fixes isPathInside()'s self-import-guard case sensitivity; this fixes scheduledImportDestinationForFile()'s relative-path calculation for external import roots. No functional overlap between the two.

Tests

  • New test: nested path preserved when import root differs only in case (Windows drive-letter). Red before fix (flattened to file.name), green after.
  • npm run test:mocks -- src/lib/scheduled-import.test.ts (13 passed)
  • npm run test:mocks (115 files, 1679 tests passed)
  • npm run typecheck

Disclosure: this focused change was produced with AI assistance and validated with the regression test, full mock suite, and typecheck.

…ws roots

scheduledImportDestinationForFile()'s containment check compares
`source === importRoot` / `source.startsWith(importRoot + "/")`
case-sensitively, but Windows drive-letter and UNC paths are
case-insensitive. When the source file's casing differs from the
configured import root (e.g. root "C:/Users/Me/Inbox", source
"c:/users/me/inbox/sub/report.pdf"), the containment check fails and
the file falls back to file.name only, silently flattening its nested
directory structure (and risking same-name collisions from different
folders).

Fix: reuse the existing drive-letter/UNC case-folding used by
dbDirectoryKey (extracted into a shared caseFoldPath helper) for the
comparison only; the returned path still uses the source's original
casing.

Verified: new test red before fix (flattened to file.name), green
after; full scheduled-import.test.ts (13) and test:mocks (1679) pass;
typecheck clean.

Note: distinct from nashsu#582 (also open, same file) — that fixes
isPathInside()'s self-import-guard case sensitivity; this fixes
scheduledImportDestinationForFile()'s relative-path calculation. No
functional overlap between the two.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant