Refresh Replaced Source Records After Import

[ptr727]

Summary

• retain the source-path cache record through a successful import
• update hashes and file metadata when content at an existing source path changes
• add a three-run regression test that proves the replacement settles to a skip

Root Cause

Import recorded every successful file through INSERT OR IGNORE. The source path is the primary key, so replacement content at an existing path left the old hashes unchanged and was imported again on every run.

The update remains after destination processing succeeds. A failed import therefore cannot be recorded as imported.

Validation

• regression test observed failing against the old write path and passing with the fix
• dotnet csharpier format --log-level=debug .
• dotnet build --verbosity=minimal (0 warnings, 0 errors)
• dotnet format style --verify-no-changes --severity=info --verbosity=detailed
• dotnet test --no-build --verbosity=minimal (368 passed, 5 skipped, 0 failed)
• dotnet husky run

Related to #48.

[Copilot]

Pull request overview

This PR fixes a long-standing import deduplication bug where replacing a file’s contents at an existing source path would still leave the old hashes in Import.db, causing the “new” file to be re-imported on every subsequent run. The change aligns ImportTask’s “record the import” behavior with the already-correct IndexTask pattern, and adds a regression test to prove the database row is refreshed and the third run settles to a skip.

Changes:

• Update ImportTask to refresh an existing source-path row via Database.UpdateHashesAsync after a successful import, instead of relying on INSERT OR IGNORE.
• Add a three-run regression test covering “import → replace source content at same path → import → verify DB updated → next run skips”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
PhotoCleaner/ImportTask.cs	Uses the pre-read source-path cache record to choose insert vs hash/metadata refresh after a successful import.
PhotoCleanerTests/ImportTaskTests.cs	Adds a regression test proving a replaced source file updates the existing DB row and the next run skips.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ptr727]

Summary

• retain the source-path cache record through a successful import
• update hashes and file metadata when content at an existing source path changes
• add a three-run regression test that proves the replacement settles to a skip

Root Cause

Import recorded every successful file through INSERT OR IGNORE. The source path is the primary key, so replacement content at an existing path left the old hashes unchanged and was imported again on every run.

The update remains after destination processing succeeds. A failed import therefore cannot be recorded as imported.

Validation

• regression test observed failing against the old write path and passing with the fix
• dotnet csharpier format --log-level=debug .
• dotnet build --verbosity=minimal (0 warnings, 0 errors)
• dotnet format style --verify-no-changes --severity=info --verbosity=detailed
• dotnet test --no-build --verbosity=minimal (368 passed, 5 skipped, 0 failed)
• dotnet husky run

Related to #48.

[Copilot]

Pull request overview

This PR fixes a long-standing import deduplication bug where replacing a file’s contents at an existing source path would still leave the old hashes in Import.db, causing the “new” file to be re-imported on every subsequent run. The change aligns ImportTask’s “record the import” behavior with the already-correct IndexTask pattern, and adds a regression test to prove the database row is refreshed and the third run settles to a skip.

Changes:

• Update ImportTask to refresh an existing source-path row via Database.UpdateHashesAsync after a successful import, instead of relying on INSERT OR IGNORE.
• Add a three-run regression test covering “import → replace source content at same path → import → verify DB updated → next run skips”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
PhotoCleaner/ImportTask.cs	Uses the pre-read source-path cache record to choose insert vs hash/metadata refresh after a successful import.
PhotoCleanerTests/ImportTaskTests.cs	Adds a regression test proving a replaced source file updates the existing DB row and the next run skips.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ptr727]

Summary

• retain the source-path cache record through a successful import
• update hashes and file metadata when content at an existing source path changes
• add a three-run regression test that proves the replacement settles to a skip

Root Cause

Import recorded every successful file through INSERT OR IGNORE. The source path is the primary key, so replacement content at an existing path left the old hashes unchanged and was imported again on every run.

The update remains after destination processing succeeds. A failed import therefore cannot be recorded as imported.

Validation

• regression test observed failing against the old write path and passing with the fix
• dotnet csharpier format --log-level=debug .
• dotnet build --verbosity=minimal (0 warnings, 0 errors)
• dotnet format style --verify-no-changes --severity=info --verbosity=detailed
• dotnet test --no-build --verbosity=minimal (368 passed, 5 skipped, 0 failed)
• dotnet husky run

Related to #48.

[Copilot]

Pull request overview

This PR fixes a long-standing import deduplication bug where replacing a file’s contents at an existing source path would still leave the old hashes in Import.db, causing the “new” file to be re-imported on every subsequent run. The change aligns ImportTask’s “record the import” behavior with the already-correct IndexTask pattern, and adds a regression test to prove the database row is refreshed and the third run settles to a skip.

Changes:

• Update ImportTask to refresh an existing source-path row via Database.UpdateHashesAsync after a successful import, instead of relying on INSERT OR IGNORE.
• Add a three-run regression test covering “import → replace source content at same path → import → verify DB updated → next run skips”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
PhotoCleaner/ImportTask.cs	Uses the pre-read source-path cache record to choose insert vs hash/metadata refresh after a successful import.
PhotoCleanerTests/ImportTaskTests.cs	Adds a regression test proving a replaced source file updates the existing DB row and the next run skips.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ptr727]

Summary

• retain the source-path cache record through a successful import
• update hashes and file metadata when content at an existing source path changes
• add a three-run regression test that proves the replacement settles to a skip

Root Cause

Import recorded every successful file through INSERT OR IGNORE. The source path is the primary key, so replacement content at an existing path left the old hashes unchanged and was imported again on every run.

The update remains after destination processing succeeds. A failed import therefore cannot be recorded as imported.

Validation

• regression test observed failing against the old write path and passing with the fix
• dotnet csharpier format --log-level=debug .
• dotnet build --verbosity=minimal (0 warnings, 0 errors)
• dotnet format style --verify-no-changes --severity=info --verbosity=detailed
• dotnet test --no-build --verbosity=minimal (368 passed, 5 skipped, 0 failed)
• dotnet husky run

Related to #48.

[Copilot]

Pull request overview

This PR fixes a long-standing import deduplication bug where replacing a file’s contents at an existing source path would still leave the old hashes in Import.db, causing the “new” file to be re-imported on every subsequent run. The change aligns ImportTask’s “record the import” behavior with the already-correct IndexTask pattern, and adds a regression test to prove the database row is refreshed and the third run settles to a skip.

Changes:

• Update ImportTask to refresh an existing source-path row via Database.UpdateHashesAsync after a successful import, instead of relying on INSERT OR IGNORE.
• Add a three-run regression test covering “import → replace source content at same path → import → verify DB updated → next run skips”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
PhotoCleaner/ImportTask.cs	Uses the pre-read source-path cache record to choose insert vs hash/metadata refresh after a successful import.
PhotoCleanerTests/ImportTaskTests.cs	Adds a regression test proving a replaced source file updates the existing DB row and the next run skips.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ptr727]

Summary

• retain the source-path cache record through a successful import
• update hashes and file metadata when content at an existing source path changes
• add a three-run regression test that proves the replacement settles to a skip

Root Cause

Import recorded every successful file through INSERT OR IGNORE. The source path is the primary key, so replacement content at an existing path left the old hashes unchanged and was imported again on every run.

The update remains after destination processing succeeds. A failed import therefore cannot be recorded as imported.

Validation

• regression test observed failing against the old write path and passing with the fix
• dotnet csharpier format --log-level=debug .
• dotnet build --verbosity=minimal (0 warnings, 0 errors)
• dotnet format style --verify-no-changes --severity=info --verbosity=detailed
• dotnet test --no-build --verbosity=minimal (368 passed, 5 skipped, 0 failed)
• dotnet husky run

Related to #48.

[Copilot]

Pull request overview

This PR fixes a long-standing import deduplication bug where replacing a file’s contents at an existing source path would still leave the old hashes in Import.db, causing the “new” file to be re-imported on every subsequent run. The change aligns ImportTask’s “record the import” behavior with the already-correct IndexTask pattern, and adds a regression test to prove the database row is refreshed and the third run settles to a skip.

Changes:

• Update ImportTask to refresh an existing source-path row via Database.UpdateHashesAsync after a successful import, instead of relying on INSERT OR IGNORE.
• Add a three-run regression test covering “import → replace source content at same path → import → verify DB updated → next run skips”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
PhotoCleaner/ImportTask.cs	Uses the pre-read source-path cache record to choose insert vs hash/metadata refresh after a successful import.
PhotoCleanerTests/ImportTaskTests.cs	Adds a regression test proving a replaced source file updates the existing DB row and the next run skips.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ptr727]

Summary

• retain the source-path cache record through a successful import
• update hashes and file metadata when content at an existing source path changes
• add a three-run regression test that proves the replacement settles to a skip

Root Cause

Import recorded every successful file through INSERT OR IGNORE. The source path is the primary key, so replacement content at an existing path left the old hashes unchanged and was imported again on every run.

The update remains after destination processing succeeds. A failed import therefore cannot be recorded as imported.

Validation

• regression test observed failing against the old write path and passing with the fix
• dotnet csharpier format --log-level=debug .
• dotnet build --verbosity=minimal (0 warnings, 0 errors)
• dotnet format style --verify-no-changes --severity=info --verbosity=detailed
• dotnet test --no-build --verbosity=minimal (368 passed, 5 skipped, 0 failed)
• dotnet husky run

Related to #48.

[Copilot]

Pull request overview

This PR fixes a long-standing import deduplication bug where replacing a file’s contents at an existing source path would still leave the old hashes in Import.db, causing the “new” file to be re-imported on every subsequent run. The change aligns ImportTask’s “record the import” behavior with the already-correct IndexTask pattern, and adds a regression test to prove the database row is refreshed and the third run settles to a skip.

Changes:

• Update ImportTask to refresh an existing source-path row via Database.UpdateHashesAsync after a successful import, instead of relying on INSERT OR IGNORE.
• Add a three-run regression test covering “import → replace source content at same path → import → verify DB updated → next run skips”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
PhotoCleaner/ImportTask.cs	Uses the pre-read source-path cache record to choose insert vs hash/metadata refresh after a successful import.
PhotoCleanerTests/ImportTaskTests.cs	Adds a regression test proving a replaced source file updates the existing DB row and the next run skips.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ptr727]

Summary

• retain the source-path cache record through a successful import
• update hashes and file metadata when content at an existing source path changes
• add a three-run regression test that proves the replacement settles to a skip

Root Cause

Import recorded every successful file through INSERT OR IGNORE. The source path is the primary key, so replacement content at an existing path left the old hashes unchanged and was imported again on every run.

The update remains after destination processing succeeds. A failed import therefore cannot be recorded as imported.

Validation

• regression test observed failing against the old write path and passing with the fix
• dotnet csharpier format --log-level=debug .
• dotnet build --verbosity=minimal (0 warnings, 0 errors)
• dotnet format style --verify-no-changes --severity=info --verbosity=detailed
• dotnet test --no-build --verbosity=minimal (368 passed, 5 skipped, 0 failed)
• dotnet husky run

Related to #48.

[Copilot]

Pull request overview

This PR fixes a long-standing import deduplication bug where replacing a file’s contents at an existing source path would still leave the old hashes in Import.db, causing the “new” file to be re-imported on every subsequent run. The change aligns ImportTask’s “record the import” behavior with the already-correct IndexTask pattern, and adds a regression test to prove the database row is refreshed and the third run settles to a skip.

Changes:

• Update ImportTask to refresh an existing source-path row via Database.UpdateHashesAsync after a successful import, instead of relying on INSERT OR IGNORE.
• Add a three-run regression test covering “import → replace source content at same path → import → verify DB updated → next run skips”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
PhotoCleaner/ImportTask.cs	Uses the pre-read source-path cache record to choose insert vs hash/metadata refresh after a successful import.
PhotoCleanerTests/ImportTaskTests.cs	Adds a regression test proving a replaced source file updates the existing DB row and the next run skips.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ptr727]

Summary

• retain the source-path cache record through a successful import
• update hashes and file metadata when content at an existing source path changes
• add a three-run regression test that proves the replacement settles to a skip

Root Cause

Import recorded every successful file through INSERT OR IGNORE. The source path is the primary key, so replacement content at an existing path left the old hashes unchanged and was imported again on every run.

The update remains after destination processing succeeds. A failed import therefore cannot be recorded as imported.

Validation

• regression test observed failing against the old write path and passing with the fix
• dotnet csharpier format --log-level=debug .
• dotnet build --verbosity=minimal (0 warnings, 0 errors)
• dotnet format style --verify-no-changes --severity=info --verbosity=detailed
• dotnet test --no-build --verbosity=minimal (368 passed, 5 skipped, 0 failed)
• dotnet husky run

Related to #48.

[Copilot]

Pull request overview

This PR fixes a long-standing import deduplication bug where replacing a file’s contents at an existing source path would still leave the old hashes in Import.db, causing the “new” file to be re-imported on every subsequent run. The change aligns ImportTask’s “record the import” behavior with the already-correct IndexTask pattern, and adds a regression test to prove the database row is refreshed and the third run settles to a skip.

Changes:

• Update ImportTask to refresh an existing source-path row via Database.UpdateHashesAsync after a successful import, instead of relying on INSERT OR IGNORE.
• Add a three-run regression test covering “import → replace source content at same path → import → verify DB updated → next run skips”.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
PhotoCleaner/ImportTask.cs	Uses the pre-read source-path cache record to choose insert vs hash/metadata refresh after a successful import.
PhotoCleanerTests/ImportTaskTests.cs	Adds a regression test proving a replaced source file updates the existing DB row and the next run skips.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.