cargo-make: Cargo make fails when run from an windows UNC mounted network drive
What I am trying to do
The cargo make file I am trying to execute is simply a Hello World from the powershell task runner. My project is located on a network drive with the UNC path \\?\UNC\ULCV\projs\murray\Code\mango. The UNC path is mapped to the system as P:\murray\Code\mango. For compatibility with tools I often have to execute a pushd . command before spawning any command line applications. See evanmcdonnal’s accepted answer on this stack exchange for an explanation of why: link
Describe The Bug
Cargo make fails in my environment when run from a UNC mounted network drive. Specifically it seems that I cannot control the current working directory that is passed to CMD.exe when it is spawned during the workspace task. I have attempted to override the UNC path by setting some environment variables but they do not seem to be respected. I suspect that injecting a pushd . before cmd.exe attempts to change directories or spawning the cmd.exe process would resolve this problem, but am too much of a rust newb to really get a good grip on where the cmd.exe process is being driven from within the project.
To Reproduce
Clone a git project containing cargo make onto a windows network file share mounted under Network File System (NFS). The drive should appear with a drive letter, but is also addressable as a UNC network path. Create a cargo make task that contains the powershell runner and have it output ‘Hello World’ to console. cargo make should fail during the workspace task when cmd.exe is spawned. cmd.exe does not understand UNC paths and thus cannot change directory to the location of the project.
Things I have tried
I have attempted to set the environment var $CARGO_MAKE_WORKING_DIRECTORY to my project root that contains the makefile.toml as a non UNC path, but the variable did not seem to impact this failure that I am seeing. I have not attempted to set $CARGO_MAKE_WORKSPACE_WORKING_DIRECTORY yet but will try that soon.
I have also attempted to control the environment by performing a pushd . before executing the cargo make command, but that did not seem to help either. As a next step I will try moving my project to the C:\ drive to test if cargo make will work with
my project, unfortunately that may not be a long term solution for me due to limitations on my C:\ drive.
Related info
I found this issue on the GitHub Page: #561, in which @WilliamVenner addressed some UNC path issues. After updating to the latest version of cargo make, so my tool chain could include the fix from issue #561, cargo make will get further along the build before failing but still has UNC pathing issues in my current environment.
Code Sample
Relevant content of makefile.toml:
[tasks.powershell]
script_runner = "powershell"
script_extension = "ps1"
script = '''
Write-Host "Hello, World!"
'''
Full File: mango_toml.zip
Error Stack
Note that CMD.exe falls over because it cannot interpret a UNC path. cargo make then falls back to C:\ as the default drive and attempts to PUSHD into my cargo workspace path: proj\frontend. that folder does not exist at the C:\ drive location so the task fails.
(base) PS P:\murray\Code\mango> cargo make --makefile .\mango.toml --task powershell
[cargo-make] INFO - cargo make 0.35.0
[cargo-make] INFO - Build File: .\mango.toml
[cargo-make] INFO - Task: powershell
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: legacy-migration
[cargo-make] INFO - Running Task: workspace
'\\?\UNC\ULCV\projs\murray\Code\mango'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
C:\Windows>cd "\\?\UNC\ULCV\projs\murray\Code\mango"
'\\?\UNC\ULCV\projs\murray\Code\mango'
CMD does not support UNC paths as current directories.
C:\Windows>PUSHD proj\frontend
The system cannot find the path specified.
C:\Windows>cargo make --disable-check-for-updates --allow-private --no-on-error --loglevel=info --env CARGO_MAKE_CRATE_CURRENT_WORKSPACE_MEMBER=frontend --profile development -- powershell
[cargo-make][1] INFO - Build File: Makefile.toml
[cargo-make][1] INFO - Task: powershell
[cargo-make][1] INFO - Profile: development
[cargo-make][1] ERROR - Task powershell not found
[cargo-make][1] WARN - Build Failed.
C:\Windows>if 1 NEQ 0 exit /b 1
[cargo-make] ERROR - Error while executing command, exit code: 1
[cargo-make] WARN - Build Failed.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (8 by maintainers)
Commits related to this issue
- Add support for windows UNC mounted network drive #581 — committed to sagiegurari/cargo-make by sagiegurari 3 years ago
- Workspace support for running on windows on UNC mounted drive #581 — committed to sagiegurari/cargo-make by sagiegurari 3 years ago
- Workspace support for running on windows on UNC mounted drive #581 — committed to sagiegurari/cargo-make by sagiegurari 3 years ago
- Workspace support for running on windows on UNC mounted drive #581 — committed to sagiegurari/cargo-make by sagiegurari 3 years ago
- Workspace support for running on windows on UNC mounted drive #581 — committed to sagiegurari/cargo-make by sagiegurari 3 years ago
@sagiegurari Yay, thanks for all of the help!
I agree that this problem sounds like cargo problem, and either way I have a path forward for my project thanks to your help.
@virtual-hexagon the original issue is now released in new official cargo-make release. thanks for the help testing. if you have more issues please open them as new ones. the current issue you are facing seems more like cargo issue than cargo-make.
@sagiegurari I built the 0.35.1 branch from source on windows and ran it in my environment. Unfortunately it did not appear to fix the problem and the behavior of the error is still unchanged. I am reviewing my verbose logs a little closer to see if I spot any changes in behavior.
I noticed that you pushed the dunce dependency down into the run_script crate, so I plan to review the run_script code a bit closer. perhaps I can log some output / run through with the debugger to better understand what is happening there when it is handling the failing task.