CLI: Volume Parsing Differences Between WSLC and Docker #14432

Volume Parsing Differences Between WSLC and Docker

Reference: wslc container run --volume

The current volume parser in WSLC is a lightweight implementation based on right-to-left (RTL) parsing. While it works well for common scenarios, it does not fully support all syntax variations currently accepted by Docker. Some of these gaps may be intentional, depending on how we choose to handle edge-case behavior.

Additionally, the parser currently allows container creation even though startup ultimately fails. Ideally, it should detect such situations earlier and return a descriptive error message before attempting to create the container.

Edge Cases That Fail in Both WSLC and Docker (Different Failure Reasons)

Although the final error surfaces from service code, the parser in WSLC produces different intermediate inputs compared to Docker.

"C:\hostPath:/containerPath:invalid_mode"
  - Docker fails because 'invalid_mode' is not a valid mode.
  - WSLC fails with ERROR_PATH_NOT_FOUND.

"C:\hostPath:/containerPath:ro:extra"
  - Docker fails due to too many colons.
  - WSLC fails with ERROR_PATH_NOT_FOUND.

"C:\hostPath:/containerPath:"
  - Docker fails because the mode is empty.
  - WSLC fails with ERROR_PATH_NOT_FOUND.

Edge Cases That Fail Only in WSLC (But Succeed in Docker)

It is currently unclear whether WSLC should support these cases (CC: Craig Loewen (@craigloewen-msft), Blue (@OneBlue)).

"C:\hostPath"
  - Docker interpretation: 'C:\hostPath' → 'C:\hostPath'

"C:/hostPath"
  - Docker interpretation: 'C:/hostPath' → ('C:' → 'hostPath')

":"
  - Docker interpretation: ':' → ':'

"::"
  - Docker interpretation: '::' → '::'

"test"
  - Docker interpretation: 'test' → 'test'

Next Steps

The existing RTL parser is intentionally lightweight and sufficient for most scenarios today. However, if broader Docker compatibility becomes a goal, we could consider implementing a more robust parser that:

• Syntactically supports a larger subset of Docker volume syntax.
• Semantically aligns with Docker’s parsing behavior.
• Ensures the service layer receives consistent and correct inputs.

This would help reduce divergence in error handling and improve overall compatibility.