Skip to content

Clarify separator format in path #563

Open

Description

Currently it is not clear what path separator should be used by a client.

For example, nvim-dap currently defaults to using /, but with adapters like netcoredbg running on windows it will expect \ in source.path. The mismatch causes breakpoints to not be set correctly.

The client could set the path separator based on the system its running on, but that breaks down if client and debugger are running on different machines for remote debugging.

One option could be to mandate in the spec that debug adapters must be able to recognize / separators.
Given that FAT16,etc. and NTFS forbids / in filenames (https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations), there would be no ambiguity - in that it can never be a part of the filename.

But I'm not sure if this won't also break down if there are 3 systems involved: client, debug-adapter, debugger and if the debug-adapter runs on a different system than the adapter.

Seems to be somewhat related to #182

Activity

  1. added a commit that references this issue on Dec 18, 2025
    2216e3b
  2. connor4312 commented on Dec 18, 2025

    @connor4312
    Member

    Thanks for the issue, I opened #581 to try to clarify it. Please let me know what you think!

  3. added this to the milestone on Dec 18, 2025
  4. added a commit that references this issue on Dec 18, 2025
    75e305f
  5. zobo commented on Dec 18, 2025

    @zobo
    Contributor

    Hi Connor Peet (@connor4312) !

    Since we have 3 tasks now, I'm not sure where to write this, but I'll pick this as mine is from 2021 and PRs aren't a good place to have a discussion.

    First, Mathias Fußenegger (@mfussenegger), I think the spec is clear, that when the client (IDE) uses pathFormat = path it must be in native format. That means on Windows it's C:\blabla\..., and possibly \\HOST\c$\share\...

    Second, the proposed and merged clarification does nothing for the root problem, presented in both issues. The DA does not know what native path format the client is sending. It only knows for sure if it's path or url, but not if it's path posix or path windows. The diff just talks about that the Source.path is only used for presentation, should Source.sourceReference be set. Both issues actually talk about the case where the client sends a concrete Source.path and the Debug Adapter needs to correctly interpret it.

    I myself solved this by some creative pattern matching and file-url. (Note to self: I also just assumed that the client always send path and not url format and need to fix this...)

    A fix that would actually solve this and let DAs deterministically know what native path format is being sent to them - and what they need to send back - would be to introduce some field in the InitializeRequestArguments that would denote what native format the paths are in - or maybe what OS the client is running on.

  6. mfussenegger commented on Jan 22, 2026

    @mfussenegger
    ContributorAuthor

    I agree that the clarification from #581 wasn't really addressing the issue. Also - looks like https://microsoft.github.io/debug-adapter-protocol/specification#Types_Source wasn't changed?

    A fix that would actually solve this and let DAs deterministically know what native path format is being sent to them - and what they need to send back - would be to introduce some field in the InitializeRequestArguments that would denote what native format the paths are in - or maybe what OS the client is running on.

    This sounds like a good option to me.

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