Skip to content

Accept a Windows drive-letter volume source #86

Closed

Description

@lesnik512

volumes: ["C:\data:/var"] with no top-level volumes: declaration is accepted by
Docker and refused by compose2pod, which is an over-rejection against the second rule
of docs/adr/0006-docker-rejection-parity.md: Docker accepts it, podman can express
it, so compose2pod should too. This is an unfinished parser, not a design position.

Measured against docker compose config v5.1.2:

  • Docker ACCEPTS. It special-cases a leading <letter>:\ so the drive letter
    stays part of the source, resolving to {source: C:\data, target: /var}.
  • compose2pod REJECTS with refers to undefined volume 'C'.

The cause is the colon-based source extraction shared by
parsing._classify_volume and emit.py's _volume_flags
(source, _, _ = volume.partition(":")). It splits on the first colon
regardless, so for this entry source is the single letter "C" — itself a
syntactically valid volume-name grammar match, not the unparseable string a naive
read of "doesn't match the name pattern" would suggest. Fixing it needs genuine
Windows-drive detection ahead of the split, in both call sites, not a
grammar-check swap.

Pre-existing since the named-volume reference check was introduced; not touched by
the tilde-bind-mount fix that discovered it. The conformance harness reports it as
over-reject, so it stays visible rather than forgotten.

Revisit trigger: a user reports a compose file that docker compose runs and
compose2pod refuses — most likely this bind.

Not in scope. Two other over-reject cells the harness reports —
sysctls: ["a"] and volumes: ["a"] — are not deferred parsers. They are measured
legitimate refusals (podman cannot form the flag), recorded in
docs/adr/0006-docker-rejection-parity.md.

Activity

  1. lesnik512 commented on Sep 20, 2026

    @lesnik512
    MemberAuthor

    Reopening: the premise this issue was closed on does not hold.

    It asserted "Docker accepts it, podman can express it, so compose2pod should too". The second half was never measured. Measured now, on podman 4.9.3 in the integration job (full table in #105):

    -v 'C:\data:/var'        exit 125  invalid option type "/var"
    -v 'C:/data:/var'        exit 125  invalid option type "/var"
    -v '/tmp/C:\data:/var'   exit 125  invalid option type "/var"
    -v '/tmp/probe-src:/var' exit 0    (control)
    

    -v splits a spec into at most source:target:options, so a colon inside the source pushes the target into the option slot. A drive letter cannot be carried through -v in any spelling, including one already resolved to an absolute path.

    So under the second rule of docs/adr/0006-docker-rejection-parity.md this was a legitimate refusal all along, not an over-rejection — and #104, which acted on this issue, made compose2pod emit a flag podman rejects at exit 125. What was actually wrong here is the part the issue described accurately: the message. refers to undefined volume 'C' names a volume the document never contains, which is what made the verdict look like a parser gap rather than a ruling.

    #107 reverses the acceptance and refuses the family with a message that cites podman. 0.4.4 was never tagged, so the acceptance did not reach PyPI.

    Closing this again once #107 lands; the remaining drive-adjacent spellings stay in #105.

  2. lesnik512 commented on Sep 20, 2026

    @lesnik512
    MemberAuthor

    #107 landed: the family is refused with a message that cites podman instead of naming a phantom volume 'C'. Closing as a measured legitimate refusal, not as the accept this issue originally asked for. The remaining drive-adjacent spellings stay in #105.

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

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions