Repository navigation
fix: return relative paths in search results - #170
DenizAltunkapan merged 3 commits into
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Agent review
The relative-path change itself looks right. One non-blocking robustness issue is in the inline comment: a symlink that resolves outside the user root can now make the whole search throw. There is no test for that case.
Generated by Pull Request Review for #170 · copilot · auto · 15.3 AIC · ⌖ 0.499 AIC · ⊞ 7.1K
|
@IhorHaidukov please fix the failing workflows |
There was a problem hiding this comment.
Agent review
One finding, inline. The relative path is computed against the real-path root, while the walked entries come from the unresolved root. If the root has a symlinked ancestor, the results contain ../ host-path fragments. Not necessarily merge-blocking, but it defeats the purpose of the fix. The existing symlink handling for #159 otherwise looks right.
Generated by Pull Request Review for #170 · copilot · auto · 15 AIC · ⌖ 0.504 AIC · ⊞ 7.1K
There was a problem hiding this comment.
Agent review
Suggestion: approve. I did not find any high-confidence correctness, security, regression, or missing-test issues in this diff.
Generated by Pull Request Review for #170 · copilot · auto · 16.3 AIC · ⌖ 0.495 AIC · ⊞ 7.1K
DenizAltunkapan
left a comment
DenizAltunkapan
left a comment
There was a problem hiding this comment.
@IhorHaidukov Thanks!
2 participants
Summary
Return user-relative paths from folder search results instead of absolute host paths.
The search result path is now resolved within the user's root directory and converted to a normalized relative path.
Added a regression test to verify that paths such as
Documents/report.txtare returned instead of absolute filesystem paths.Linked issue
Closes #159
How to test
FolderServiceTestpasses: 72 tests, 0 failures, 0 errors.searchInFoldertests pass.FileServiceTest.