Very likely a new bug in SDK container build in VSCode

Technical Support
, ,
1

So I tried to rebuild the SDK this morning in VSCode and the process is failing here:

[4631 ms] Start: Starting container
[4632 ms] Start: Run: docker run --sig-proxy=false -a STDOUT -a STDERR --mount type=bind,source=z:\Docs\tarform\code\founders,target=/workspaces/founders,consistency=cached --mount source=C:\Users\fireeC:\Users\firee/.moses,target=/home/torizon/.moses,type=bind --mount source=//var/run/docker.sock,target=/var/run/docker.sock,type=bind --mount source=c:\Users\firee\.vscode\extensions\toradex.torizon-1.3.0,target=/home/torizon/.torizon-extension,type=bind --mount type=volume,src=vscode,dst=/vscode -l vsch.local.folder=z:\Docs\tarform\code\founders\tarform -l vsch.quality=stable -l vsch.remote.devPort=0 -e AR=arm-linux-gnueabihf-ar -e AS=arm-linux-gnueabihf-as -e CC=arm-linux-gnueabihf-gcc -e CXX=arm-linux-gnueabihf-g++ -e CPP=arm-linux-gnueabihf-cpp -e STRIP=arm-linux-gnueabihf-strip -e LD=arm-linux-gnueabihf-ld -e CROSS_COMPILE=arm-linux-gnueabihf- -e QMAKE=arm-linux-gnueabihf-qmake -e QT_INCLUDES=/usr/include/arm-linux-gnueabihf/qt5 --network=host --entrypoint /bin/sh vsc-tarform-f5b799831addd84f05f587dff0335418 -c echo Container started
docker: Error response from daemon: CreateFile C:\Users\fireeC:\Users\firee\.mos
es: The filename, directory name, or volume label syntax is incorrect.
See 'docker run --help'.
[5603 ms] Start: Run: docker ps -q -a --filter label=vsch.local.folder=z:\Docs\tarform\code\founders\tarform --filter label=vsch.quality=stable
[6363 ms] Command failed: docker run --sig-proxy=false -a STDOUT -a STDERR --mount type=bind,source=z:\Docs\tarform\code\founders,target=/workspaces/founders,consistency=cached --mount source=C:\Users\fireeC:\Users\firee/.moses,target=/home/torizon/.moses,type=bind --mount source=//var/run/docker.sock,target=/var/run/docker.sock,type=bind --mount source=c:\Users\firee\.vscode\extensions\toradex.torizon-1.3.0,target=/home/torizon/.torizon-extension,type=bind --mount type=volume,src=vscode,dst=/vscode -l vsch.local.folder=z:\Docs\tarform\code\founders\tarform -l vsch.quality=stable -l vsch.remote.devPort=0 -e AR=arm-linux-gnueabihf-ar -e AS=arm-linux-gnueabihf-as -e CC=arm-linux-gnueabihf-gcc -e CXX=arm-linux-gnueabihf-g++ -e CPP=arm-linux-gnueabihf-cpp -e STRIP=arm-linux-gnueabihf-strip -e LD=arm-linux-gnueabihf-ld -e CROSS_COMPILE=arm-linux-gnueabihf- -e QMAKE=arm-linux-gnueabihf-qmake -e QT_INCLUDES=/usr/include/arm-linux-gnueabihf/qt5 --network=host --entrypoint /bin/sh vsc-tarform-f5b799831addd84f05f587dff0335418 -c echo Container started
trap "exit 0" 15

while sleep 1 & wait $!; do :; done

I’ve got a hunch the the error docker: Error response from daemon: CreateFile C:\Users\fireeC:\Users\firee\.mos es: The filename, directory name, or volume label syntax is incorrect. correctly identifies that the path C:\Users\fireeC:\Users\firee\.mos does not exist on my system… I’ll try the bleeding edge version of the VSCode plugin…

2

Not testing the early access… Manually removing ${localEnv:HOME} from the autogenerated devcontainer.json “mounts” section worked for the moment.

3

Greetings @ed-bear,

Just some questions about your situation.

Going by the file paths in your post, it appears you are using our VSCode extension on a Windows machine. Is that correct?

Also Is this issue something you can easily reproduce from scratch? It seems like here it only happened when rebuilding the SDK for an already existing project. It would be helpful for debugging if you knew of a way to reproduce this with a fresh project.

Best Regards,
Jeremias

4

  • Yep, windoze.

  • I don’t have time to re-import the project into a fresh environment, but this was rebuilding an existing, working project.

  • Unclobbering the .moses mount path is working

5

Hmm interesting, well I’m not able to reproduce this on my own Windows setup. If you figure out any more information regarding this potential bug please let us know so that we can work on fixing it.

6

Fresh install on a new Windows 11 machine, literally fresh VSCode, Docker Desktop, etc.

Simply selecting running @command:torizon.createCCPPApp AKA Torizon: Create new C++ … is unable to start the local container because of (I think) the clobbered path to moses in devcontainer.json:
source=${localEnv:HOME}${localEnv:USERPROFILE}/.moses,target=/home/torizon/.moses,

docker: Error response from daemon: CreateFile C:\Users\tarfoC:\Users\tarfo\.mos

es: The filename, directory name, or volume label syntax is incorrect.
7

Is this issue related to the original issue you shared here almost over a year ago? Or is this brand new? In which case a new post might make more sense.

Also our extensions have not been tested or validated on Windows 11.

Best Regards,
Jeremias

8

It was exactly the same issue as before, but I had forgotten about it until setting up a new development machine. The issue is that the autogenerated ‘devcontainer.json’ concatenates ${localEnv:HOME}${localEnv:USERPROFILE} in the path to moses. If both variables are defined, the moses path is invalid. Not really an OS specific problem.

9

I’ve never seen the issue reported by other Windows users so far. On your setup both HOME and USERPROFILE are defined? Is this a default setting on your corporate machines perhaps?

I’ll report the issue but for the time being you’ll need to work-around it like you did before.

Best Regards,
Jeremias

10

I was facing the same issue and your solution worked!