Quality: Path joining logic creates double slashes

[tomaioo]

Summary

Quality: Path joining logic creates double slashes

Problem

Severity: High | File: packages/filesystem/utils.ts:L3

In packages/filesystem/utils.ts, the joinPath function adds a leading '/' to every path segment that doesn't already start with '/', which creates incorrect paths with double slashes like '//path1//path2' instead of '/path1/path2'. The logic incorrectly prepends '/' to values that already have it stripped.

Solution

Fix the path joining logic to properly handle the first segment vs subsequent segments. Consider using path.join() or a proper path separator handling.

Changes

• packages/filesystem/utils.ts (modified)

[cyfung1031]

@tomaioo thanks for looking into this.

I think this change is not safe to merge as-is. The current implementation appears to keep an absolute-style path contract: non-empty joined paths start with /. With this PR, cases like joinPath("", "file.txt") or joinPath("path1", "path2") now return file.txt / path1/path2 instead of /file.txt / /path1/path2.

That can break callers where the base path may be empty. For example, Dropbox initializes the root path as "", and calls like joinPath(this.path, path) are passed directly to the Dropbox API. Returning a relative path there is likely incorrect.

A safer fix would be to preserve the existing absolute-path behavior while normalizing duplicated slashes. I have just committed the change.

Unit tests have also been added.

[cyfung1031]

Approved as per 57bd0ca

[cyfung1031]

@CodFrm it might affect if there are double slashes in the existing storage. I am not sure whether we have such a case. please check.

Example

• expect(joinPath("/ScriptCat//sync", "foo.js")).toBe("/ScriptCat/sync/foo.js");

[CodFrm]

@CodFrm it might affect if there are double slashes in the existing storage. I am not sure whether we have such a case. please check.

Example

• expect(joinPath("/ScriptCat//sync", "foo.js")).toBe("/ScriptCat/sync/foo.js");

I can't think of a scenario where double slashes would end up in storage, unless a caller has a code quality issue that produces malformed paths.

The only place I can think of that might carry this risk is CAT_fileStorage.