Path mappings not working with mixed windows-style/linux path slash

[gionapaolini]

I have a launch.json configuration to attach the debugger to a remote service.
This used to work for a long time, not sure when it stopped working exactly.

{
            "name": "Service1",
            "type": "python",
            "request": "attach",
            "connect": {
                "host": "localhost",
                "port": 6005
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceRoot}/Source",
                    "remoteRoot": "/app"
                }
            ],
            "logToFile": true,
            "justMyCode": false
        }
      ...
}

Gives error:

pydev debugger: unable to find translation for: "c:\path\to\workspace\Source\...\app.py" in ["C:\path\to\workspace/Source/","C:\path\to\workspace/Source"] (please revise your path mappings).

The local root is translated into
C:\path\to\workspace/Source/ (notice the forward slashes at the end, and capital C )
While the pydev debugger is looking for
c:\path\to\workspace\Source\...\app.py

I tried several ways to make it work, by replacing the ${workspaceRoot} variable with the value with lower c, and correct slashes.
But the only way I managed to make it work is to map exactly the full path of the specific file I want to debug. That's the only way I could see and hit the breakpoint on vscode window.

            "pathMappings": [
                {
                    "localRoot": "c:\\path\\to\\workspace\\Source\\...\\app.py",
                    "remoteRoot": "/app/../app.py"
                }
            ]

There are other ways I have tried, many variations with the slashes, but none of them worked. Also sometimes I don't receive the error above, but rather only Breakpoint in file that does not exist.

Is this a vscode issue or debugpy issue?

[gramster]

@karthiknadig, does this seem like debugpy or PVSC?

[karthiknadig]

For this can you try adding "clientOS": "windows" to the configuration? This can occur when debugpy is not able to identify the client OS from the server side.

[karthiknadig]

If you are using the latest version of python extension which is 2023.8.* and debugpy 1.6.7 and you are seeing this issue let us know. It could also be a bug in Python extension where the client OS is not being explictly sent to debugpy.

[andreeas26]

If you are using the latest version of python extension which is 2023.8.* and debugpy 1.6.7 and you are seeing this issue let us know. It could also be a bug in Python extension where the client OS is not being explictly sent to debugpy.

Hi! I am having the same problem. My python extension is 2023.10, but debugpy is 1.5.1 because I am using a rather old version of python. I cannot add "clientOS" to the configuration. I get: Property "clientOS" is not allowed. Below you can see my configuration file. Do you think I should downgrade the python extension? It's a bit more difficult to update the environment I am using.

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Remote Attach",
            "type": "python",
            "request": "attach",
            "connect": {
                "host": "localhost",
                "port": 2599
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "."
                }
                
            ],
            "justMyCode": true,
        }
    ]
}

[karthiknadig]

If you are seeing this you can ignore the warning:

Which version of python extension are you using?

[andreeas26]

If you are seeing this you can ignore the warning:

Which version of python extension are you using?
I use v2023.10.0. It still doesn't work even with "clientOS"

[devmessias]

Any news about this issue?

[rchiodo]

Did you try this suggestion?

            "pathMappings": [
                {
                    "localRoot": "c:\\path\\to\\workspace\\Source\\...\\app.py",
                    "remoteRoot": "/app/../app.py"
                }
            ]

Putting the full path to a file in the path mappings?

[devmessias]

No, this is used by multiple employees. I'm looking for a solution using {workspace} to avoid everyone changing the launch.json for each specific folder. In addition, I tried to declare clientOS, but I got the following warning, which is strange because I looked inside the debugpy code and it seems that this is a valid argument.

[justynbell]

I'm having this same issue.

VSCode: 1.96.2
Python Debugger plugin: 2024-12-11
pydebug (on remote): 1.5.1

Putting the full path in localRoot works: "localRoot": "c:\\dev\\test\\
Using: "localRoot": "${workspaceFolder}", Does not.

When using the ${workspaceFolder} localRoot, pydebug spits out:

pydev debugger: unable to find translation for: "c:\dev\test\Test.py" in ["C:\dev\test/", "C:\dev\test"] (please revise your path mappings).

It's some issue with either the slashes, or the "c" vs "C", I don't know.

Is there a workaround, because hard-coding paths is not acceptable in my use-case either.

Using the "clientOS": "windows" property doesn't change anything for me.

[rchiodo]

I would hazard a guess that VS code changed the result for ${workspaceFolder} to be upper case. Debugpy doesn't do the expansion of the ${workspaceFolder} variable AFAIK, that happens on the VS code side as Debugpy knows nothing of the workspace.

We'll likely have to do case insensitive lookups. Not sure why it wasn't already doing this for windows.

The translation happens here:

debugpy/src/debugpy/_vendored/pydevd/pydevd_file_utils.py

Line 761 in 02723de

def _map_file_to_server(filename, cache=norm_filename_to_server_container):