Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide the option to resolve relative workspace path as symlinked path, not real path #932

Open
ThePlenkov opened this issue Nov 18, 2024 · 9 comments
Assignees
Labels
bug Something isn't working upstream Issue identified as 'upstream' component related (exists outside of Dev Containers CLI)

Comments

@ThePlenkov
Copy link

Hi,

This issue is a follow-up issue for those following issues:

So the problem is following, somehow docker CLI doesn't like to mount folders, which are mount to WSL at same time. However if this folder like /mnt/wsl/workspace symlinked to something like ~/workspace , then when I mount it from ~/workspace - it works. However it doesn't work in VS Code, because it still resolves path to real path.

So I tried to test it just with devcontainers CLI and here is what I see:

If I run like this:

cd ~/workspace
devcontainer up --workspace-folder .

Then it doesn't work. It means that container is up and running, but workspace folder in the devctontainer is empty - there are no files. In Docker Desktop I can see that it resolves . into /mnt/wsl/worspace

However when I run the command like this:

devcontainer up --workspace-folder /home/myuser/workspace

Then devcontainer is up but also files are there. In the Docker Desktop I can see that the path is not changed.

So what I'd like CLI to do - whenever I provide a relative path like ., can it please follow cwd where I am in and not resolve it to a real path?

@Mathiyarasy Mathiyarasy self-assigned this Nov 27, 2024
@chrmarti
Copy link
Contributor

chrmarti commented Dec 17, 2024

We are using path.resolve(process.cwd(), workspaceFolderArg) to resolve the relative path. That seems to preserve the symlink and I would expect it to behave the same as with the absolute path to the symlinked folder.

@chrmarti
Copy link
Contributor

chrmarti commented Dec 17, 2024

My above comment is incorrect: node -p 'process.cwd()' prints the target path and not the symlinked path. For some reason Node.js follows the symlink for that.

@chrmarti chrmarti added the bug Something isn't working label Dec 17, 2024
@ThePlenkov
Copy link
Author

@ThePlenkov
Copy link
Author

@chrmarti is there a way to use something like process.env.PWD ? process.env.PWD : process.cwd( ). I mean in Windows it just doesn't make sense. But for UNIX systems it would work perfectly

@ThePlenkov
Copy link
Author

As alternative - devcontainer to provide the option/flag to set cwd explicitly. So we can just run something like devcontainers up --cwd=$pwd

@ThePlenkov
Copy link
Author

ThePlenkov commented Dec 20, 2024

@chrmarti I'm not sure if it matters, but I noticed in the console when I start a container:

Running Dev Containers CLI:   up --container-session-data-folder /tmp/devcontainers-aca8bcf8-4f9a-49a1-abe5-a3dccf5bf7f51734715720359 --workspace-folder /mnt/wsl/workspace/ubuntu/payops-service-db --workspace-mount-consistency cached 

I honestly have no idea - but just thought - is there a way to switch this mount consistency somehow and not to produce this --workspace-mount-consistency cached ?

I would like to use it only as a test

Thanks

@chrmarti
Copy link
Contributor

@ThePlenkov The Dev Containers extension has a setting for that:

Image

@ThePlenkov
Copy link
Author

Yes I saw it unfortunately it didn't help to solve my issue

@chrmarti
Copy link
Contributor

This seems to be a Docker issue: docker/for-win#14380

@chrmarti chrmarti added the upstream Issue identified as 'upstream' component related (exists outside of Dev Containers CLI) label Jan 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working upstream Issue identified as 'upstream' component related (exists outside of Dev Containers CLI)
Projects
None yet
Development

No branches or pull requests

3 participants