Very likely a new bug in SDK container build in VSCode

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…

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

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

  • 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

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.