Skip to content

microcks import truncates Windows absolute paths when parsing :primary suffix #352

Open

Description

@hazelmayank

Describe the bug

microcks import supports an optional :true / :false suffix to mark whether an imported artifact is the main artifact. However, the current parser at cmd/import.go:126 uses strings.Split(f, ":"), which also splits Windows-absolute paths on the drive-letter colon. A path such as:

C:\Temp\api.yaml

is therefore truncated to just C, and the remainder is treated as the boolean suffix — which then fails to parse, falls back to mainArtifact = true, and the upload step opens C (which does not exist).


Expected behavior

Windows-absolute paths should be preserved as full file paths.

C:\Temp\api.yaml should be parsed as:

path         = C:\Temp\api.yaml
mainArtifact = true

C:\Temp\api.yaml:false should be parsed as:

path         = C:\Temp\api.yaml
mainArtifact = false

The existing documented suffix behavior should continue to work for relative paths:

./api.yaml         -> path = ./api.yaml, mainArtifact = true
./api.yaml:true    -> path = ./api.yaml, mainArtifact = true
./api.yaml:false   -> path = ./api.yaml, mainArtifact = false

In short: the parser should be able to tell the drive-letter colon apart from the suffix-separator colon.


Actual behavior

The current parser splits on every colon and only ever inspects parts[1].

A Windows path like C:\Temp\api.yaml is parsed as:

parts        = ["C", "\Temp\api.yaml"]
path         = "C"
mainArtifact = true   (strconv.ParseBool fails on "\Temp\api.yaml", default is true)

A Windows path with an explicit suffix like C:\Temp\api.yaml:false is parsed as:

parts        = ["C", "\Temp\api.yaml", "false"]
path         = "C"
mainArtifact = true   (only parts[1] is read; the trailing "false" is never seen)

In both cases the subsequent upload fails with open C: no such file or directory, with no hint that the parser silently truncated the path.


How to Reproduce?

  1. On Windows, place an OpenAPI file at C:\Temp\api.yaml.
  2. Build the CLI: make build-local.
  3. Run:
    ./build/dist/microcks.exe import C:\Temp\api.yaml --microcksURL http://localhost:8585
  4. Observe the failure: open C: no such file or directory (sometimes preceded by Cannot parse '\Temp\api.yaml' as Bool, default to true).

The same shape of bug is reproducible on Linux/macOS by passing a path that contains a colon, e.g. path:with:colon.yaml.


Microcks version or git rev

No response


Install method (docker-compose, helm chart, operator, docker-desktop extension,...)

No response


Additional information

Root cause. cmd/import.go:125-131 parses each comma-separated entry by:

if strings.Contains(f, ":") {
    pathAndMainArtifact := strings.Split(f, ":")
    f = pathAndMainArtifact[0]
    mainArtifact, err = strconv.ParseBool(pathAndMainArtifact[1])
    ...
}

Activity

  1. hazelmayank commented on May 9, 2026

    @hazelmayank
    ContributorAuthor

    Opened a PR with a parser helper and table-driven tests for Windows path handling in microcks import.

  2. yada commented on Oct 14, 2026

    @yada
    Member

    Reproduced on master (f9550f5). microcks import 'C:\Temp\api.yaml' gives cannot parse "\Temp\api.yaml" as artifact primary flag (exit 2), and C:\Temp\api.yaml:false fails the same way. The parser splits on every :, so the drive-letter colon is taken as the suffix separator. This also shows on macOS because it is pure string parsing, and relative paths with :true/:false work. Still valid.

  3. yada commented on Oct 17, 2026

    @yada
    Member

    Update: PR #588 ("preserve Windows drive-letter and colon-containing paths") looks like it addresses this. I built its head on macOS and ran microcks import 'C:\Temp\api.yaml'. It now tries to read C:\Temp\api.yaml as a file (cannot read artifact ... no such file, exit 2) instead of master's cannot parse "\Temp\api.yaml" as artifact primary flag. ver.yaml:false still sets the primary flag correctly. I could not test on real Windows.

    Disclosure: this comment was drafted with AI assistance, and the results were run locally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions