I am running a build from Team Foundation Server(TFS), and the build is failing with the error
"xcopy "C:\eComObjects_MP10\Microsoft\DynamicsCrm"
"D:\Builds\19\Unicorn\MaintPackage10- Daily\Sources\MaintPackage10\WebInterface\Store\Inetpub\wwwroot\Bin\DynamicsCrm"
/E /Y /I " exited with code 4".
When I simply go to the command prompt and run the above command, it fails, but when this command is run after removing /E/Y/I and the double quotes at the end, it works fine from the command prompt. What might be wrong here ?
Since it's also failed with command prompt, so it's not related to TFS build.
Xcopy exit code 4 means "Initialization error occurred. There is not
enough memory or disk space, or you entered an invalid drive name or
invalid syntax on the command line."
There are various reasons for this. In your case it may due to the length of Source and Destination (Path length). resulting path names exceeded the maximum allowed length. It may due to the /e option /e : Copies all subdirectories, even if they are empty. Use /e with the /s and /t command-line options. Xcopy command reference.
For more ways, you could refer below similar question:
What is going wrong when Visual Studio tells me "xcopy exited with code 4"
Command copy exited with code 4 when building - Visual Studio restart solves it
In addition to the possibility of disk space or command line syntax errors, this can also occur due to permissions (and maybe other causes?)
What I would recommend is to open a command prompt and copy/paste the offending XCOPY command so you can see the actual error that's occurring. In my case it was "Access Denied" which prompted me to check the destination folder where I found that my user account didn't have appropriate access.
Related
The command
xcopy "$SITEPACKAGES\\google" "build\\lib\\google" /i /e /h fails with Invalid number of parameters on Windows on AppVeyor (Visual Studio 2019).
I’ve confirmed the correct syntax of the command in my Windows virtual machine on my computer where the command works as expected, and I’ve confirmed the correct setting of the $SITEPACKAGES variable and the escaped backslashes by echoing the same line: echo "$SITEPACKAGES\\google" "build\\lib\\google" /i /e /h produces C:\Python37-x64\Lib\site-packages\google build\lib\google /i /e /h, now with the quotes not showing anymore as expected.
The command is run from a shell schript as a normal command from appveyor.yml like so:
build_script:
- cmd: "sh wxPython/build/Windows/build-all.sh"
I’ve also tried not to escape the backslashes, but with same result.
I'm lost. Any ideas?
I believe there are some backslashes missing, as you can see from my attempts:
C:\Users\Gebruiker>xcopy C:\Python37-x64\Lib\site-packages\google build\lib\google /i /e /h
File not found - google
0 File(s) copied
C:\Users\Gebruiker>xcopy C:\Python37-x64\Lib\site-packages\google\ build\lib\google\ /i /e /h
Invalid path
0 File(s) copied
Anyway, I'd advise to make sure you always have double quotes around your paths, you never know when a space might arrive in a directory's name.
Still not sure yet what the problem is, but it has shown in another instance that there’s some real problem here. My other question shows a similar behaviour. It seems that options are being interpreted as file name input.
Meanwhile I've wanted to post a workaround that helped me, which is to copy through Python:
python -c "import shutil; shutil.copytree('$SITEPACKAGES\\google', 'build\\lib\\google')"
Found the cleanest solution: Don't mix Windows and Linux (WSL) environments in AppVeyor (or probably generally).
Either call a shell script using sh or bash and then copy folders the Unix way with cp -r $SITEPACKAGES/google build/lib/ with appveyor.yml:
build_script:
- cmd: sh somecommand.sh
or do it the Windows way and call a Windows batch script directly and then use Windows’ copy commands xcopy "$SITEPACKAGES\\google" "build\\lib\\google" /i /e /h with appveyor.yml:
build_script:
- somecommand.bat
On Windows 7 SP1, from CMD window, run command regsvr32 none.dll, regsvr32 will fail with exit code 3. This is the expected behavior of regsvr32, as stated in Raymond Chen's blog post.
Procmon verifies this as well.
However, when checking regsvr32's exit code with echo %ERRORLEVEL%, I got zero. WHY?
Thanks to Marks comment. I was just tripped by CMD's sneaky behavior.
To know the exit code of a GUI process like regsvr32, the CMD command line has to be:
start /wait regsvr32.exe none.dll
What is special about regsvr32 is: If we run regsvr /s xxx.dll , /s makes regsvr totally silent, looking very much like a CUI program. So users are more easily get trapped.
But if we execute regsvr32 none.dll inside a .bat/.cmd batch script, start /wait is not required. Such discrepancy (on command prompt vs inside batch script) often causes trouble for the unwary. Sigh.
I have a batch file running on Windows 7 x86. I am trying to script a connection to a share and then once that is done to execute an app.
net use \\appserver001\mycompany.ptshare\OPS /user:geek xyz!## /persistent:yes
echo %errorlevel%
if errorlevel 2 goto message
if errorlevel 1 goto message
start "" "\\appserver001\mycompany.ptshare\OPS\OPSapp.exe"
echo %errorlevel%
if errorlevel 2 goto message
if errorlevel 1 goto message
goto end
:message
cls
echo ERROR IN CONNECTING TO SERVER
:end
The NET USE connection is made as the command window says "The command completed successfully". Then when it reaches the line to execute the app I get a pop-up message "Invalid location for program!".
I swear I have done his before but cant figure out why it will not run my app.
"Invalid location for program!" sounds like an error message that could come from OPSapp.exe itself. You could verify that by opening Task Manager and checking whether OPSapp is listed in the Processes tab when the error pops. If that's not the case then you may ignore the rest of this post.
Some programs require to be launched from a drive-letter based path (e.g. X:\etc\app.exe) rather than a UNC path (e.g. \\srv\etc\app.exe). Such a program can check at startup the location where it's been started from, then pop an error message and exit if it's a UNC path, instead of the drive-letter based one it expects.
The workaround in such cases is to (temporarily) map a drive letter to the network share, then use it to launch the program. For example, in your case replace
start "" "\\appserver001\mycompany.ptshare\OPS\OPSapp.exe"
with
pushd "\\appserver001\mycompany.ptshare\OPS"
start "" "OPSapp.exe"
If this still doesn't work, then it's possible that OPSapp expects more than just a drive-letter based path, perhaps a particular directory structure someplace, or registry entries etc - in other words it may not be portable enough to be simply runnable by path.
I'm trying to delete a folder in my output directory using the following command line:
del /F "$(TargetDir)Content\"
Tho I always end up exiting with error code 1. I've tried several different ways, without /F, with/without slash both before and after, etc.
Error 1 The command "del /F "E:\proj\bin\Windows\Debug\Content\"" exited with code 1.
There are a lot of questions regarding deleting files in post-build event command lines in visual studio, which works fine, but I can't seem to delete a folder without getting code 1.
Any help is appreciated!
RD /S /Q "Full Path of Folder"
In your case:
RD /S /Q "$(TargetDir)Content\"
Browse to the same folder using Command Prompt, and then run that command and see what the actual error is. Might be permissions or something is in use.
As much as this topic has been talked about, I would think that someone else has run into the same issue as me and found a solution.
This XCOPY Script works in another environment using VS 2012 (with macros) and the same environment using the command line.
XCOPY "C:\Web.Forms\bin\Web.Forms.dll" "C:\inetpub\WebSite\bin" /Y /R
XCOPY "C:\Web.Forms\UserControls\*.ascx" "C:\inetpub\WebSite\usercontrols" /Y /R
It keeps throwing an error of 4 and does not copy within VS 2013. If I change it to "COPY" I get an error of 1. For the purpose of testing and to use it in the command line I stripped it of all Macro's. Actually, I used the [macro] generated directory strings from the error message successfully in the command line.
So why doesn't this work in Visual Studio 2013? VS is running as Administrator.