#146 receive_files rejects all paths on Windows remote members (work_folder path resolution bug)

[Anonymous]

Originally created by: kumaakh

Problem

receive_files always fails with remote_path "<path>" resolves outside member work_folder — read blocked on Windows remote members, regardless of path format used.

Steps to reproduce

Member registered with work_folder: C:\Users\aUser\ODM. All of the following path formats are rejected:

"build\logs\net.log"       → resolves outside member work_folder — read blocked
"build/logs/net.log"         → resolves outside member work_folder — read blocked
"net.log"                    → resolves outside member work_folder — read blocked
"C:\Users\aUser\ODM\net.log" → resolves outside member work_folder — read blocked

Expected behaviour

Relative paths like build/logs/net.log should resolve against the work folder (C:\Users\aUser\ODM) to C:\Users\aUser\ODM\build\logs\net.log and be allowed.

Root cause (suspected)

The path resolution logic likely uses a Unix-style string prefix check (e.g. checking that the resolved path starts with the work folder string). On Windows, the work folder uses backslashes but the resolved path may use forward slashes (or vice versa), causing the prefix check to fail even when the path is genuinely inside the work folder.

Related

• [#144] — SSH usernames containing spaces rejected
• [#145] — Windows SSH members: OpenSSH default shell configuration

[Anonymous]

Originally posted by: kumaakh

Fixed in main: PR [#174] (fix: ESM __dirname shim + Windows path rejection in send/receive_files) added isContainedInWorkFolder() in src/utils/platform.ts which correctly normalizes both backslash and forward-slash paths before comparison. Absolute Windows paths (e.g. C:\Users\aUser\ODM\net.log), relative paths with forward slashes, and bare filenames are all handled. The remote member path security check in src/tools/receive-files.ts now uses this utility for non-local members.

[Anonymous]

Ticket changed by: kumaakh

• status: open --> closed