You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Activity
fix: clarify expectations around source.path format
connor4312 commentedon Dec 18, 2025
Thanks for the issue, I opened #581 to try to clarify it. Please let me know what you think!
fix: clarify expectations around source.path format (microsoft#581)
zobo commentedon Dec 18, 2025
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=pathit must be in native format. That means on Windows it'sC:\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
pathorurl, but not if it'spath posixorpath windows. The diff just talks about that theSource.pathis only used for presentation, shouldSource.sourceReferencebe set. Both issues actually talk about the case where the client sends a concreteSource.pathand 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 sendpathand noturlformat 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
InitializeRequestArgumentsthat would denote what native format the paths are in - or maybe what OS the client is running on.mfussenegger commentedon Jan 22, 2026
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?
This sounds like a good option to me.