fix: preserve nested scheduled-import paths on case-insensitive Windows roots#583
Open
chuenchen309 wants to merge 1 commit into
Open
Conversation
…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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
scheduledImportDestinationForFile()'s containment check comparessource === 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. rootC:/Users/Me/Inbox, sourcec:/users/me/inbox/sub/report.pdf), the containment check fails and the file falls back tofile.nameonly — 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 sharedcaseFoldPathhelper) 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 fixesscheduledImportDestinationForFile()'s relative-path calculation for external import roots. No functional overlap between the two.Tests
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 typecheckDisclosure: this focused change was produced with AI assistance and validated with the regression test, full mock suite, and typecheck.