Creating junctions in Windows for Hudson build - command-line

I have a job in Hudson that builds on a Windows XP slave. I know that symlinks are not possible (directly) in Windows XP, and so I am trying to use junctions instead. I wrote a batch script:
#echo off
if "%1" == "" goto ERROR1
if "%2" == "" goto ERROR2
goto create
:create
echo Creating junction for %1 at %2
if exist %2 junction -q -d %2
md %2
junction -q %2 %1
goto :eof
:ERROR1
echo Source directory not specified
goto :eof
:ERROR2
echo Destination directory not specified
goto :eof
In my job, when I call this script, it hangs at the line echo Creating junction for %1 at %2. This is my Hudson "Execute Windows Batch Command":
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
copy C:\Data\Scripts\slink.bat .
call slink.bat C:\Data\3rdParty64 3rdParty
call slink.bat %WORKSPACE%\..\..\..\tds.core\label\%label% tds.core
...and this is the output:
C:\Data\Hudson\dev\workspace\Common_Windows\label\DFWW9202>call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
Setting environment for using Microsoft Visual Studio 2010 x64 tools.
1 file(s) copied.
Creating junction for C:\Data\3rdParty64 at 3rdParty
Any ideas? (if this is not the right site, please redirect..sorry and thanks!)

The best way to solve this is to: pass /accepteula command-line argument to the junction command.
eg:
junction -q %2 %1 /accepteula

This procedure did not work for me, but I did narrow down the real problem.
Some background: The very first time the "junction.exe" program is ever run by a user on a Windows machine, it throws up an End User License Agreement (EULA) with an Agree button. Once that user clicks on the "Agree" button, they can use the utility normally.
junction.exe was stalling for Hudson because the service was being run as "Default User", and "Default User" never clicked on the Agree button. This caused junction.exe to invisibly and indefinitely stall, waiting for that click, which of course will never arrive.
The way we fixed it was to configure the system to run the Hudson service as a well known account, instead of as Default User. Then we logged into the Windows machine as that account, ran junction.exe, clicked on the Agree button, then logged off.
junction.exe has worked nicely in Hudson ever since.
The other option is to move to Windows Server 2008. I'm told that version has the junction functionality in a new "mklink" utility that comes built into the OS itself, and does not have a EULA.

Never mind, found it if anyone else is looking - I changed the "call" to slink.bat to "start /B", and added full paths, so:
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
start /B C:\Data\Scripts\slink.bat C:\Data\3rdParty64 3rdParty
start /B C:\Data\Scripts\slink.bat slink.bat %WORKSPACE%\..\..\..\tds.core\label\%label% tds.core

Related

How to call an application shortcut in PowerShell and pass arguments

I need to call MSTEST.exe passing arguments as "elevated/admin" from an account which is not an admin, and cannot be. I have created a short cut for MSTest.exe called "MSTest_Elevated.lnk". I can call this and pass parameters via command line and everything works fine, see below:
REM Set up test executable variables
REM SET MSTEST_EXECUTABLE="C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\mstest.exe"
SET MSTEST_EXECUTABLE="C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest_Elevated.lnk"
SET NUNIT_EXECUTABLE="C:\Program Files (x86)\NUnit 2.6.4\bin\nunit-console.exe"
CD %WORKSPACE%
SET WORKSPACE_TEST_RESULTS=%WORKSPACE%\TestResults_Integration
REM Create test result folder
IF NOT EXIST "%WORKSPACE_TEST_RESULTS%\" ECHO "Creating %WORKSPACE_TEST_RESULTS%"
IF EXIST "%WORKSPACE_TEST_RESULTS%\" ECHO "%WORKSPACE_TEST_RESULTS% EXISTS"
IF NOT EXIST "%WORKSPACE_TEST_RESULTS%\" md "%WORKSPACE_TEST_RESULTS%"
REM Run the tests
%MSTEST_EXECUTABLE% /resultsfile:"MyServiceTestsResults.trx" /testcontainer:"MyService\Test\Unit\MyServiceTests\bin\Release\MyServiceTests.dll" /nologo
REM Clear up test executable variables
SET MSTEST_EXECUTABLE=
SET NUNIT_EXECUTABLE=
However my solution cannot use command line and needs to use PowerShell. I can call MSTEST from PowerShell like so, but not as admin. It also fails if I try and call the elevated shortcut.
Execute-Command -commandTitle "MSTest" -commandPath "`"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\mstest.exe`"" -commandArguments "/xml:`"MyServiceTestsResults.trx`" `"MyService\Test\Unit\MyServiceTests\bin\Release\MyServiceTests.dll`" /nologo ";
The shortcut seems to run without failing but MSTEST does not get called. So...
Is there a way to call MSTest.exe via the elevated shortcut, with parameters in the same way in PowerShell as I can from call it from a BAT file?

How do I tell eclipse that an external tool is done executing?

The Eclipse IDE has a feature where one could run external tools. I use it to run batch scripts. Oddly if a batch script runs a powershell command, the powershell command will never exit until I hit enter. This is especially odd since it exits just fine when running in cmd. How should I correct my script so that it runs as expected via the eclipse external tools?
Current script (foo.bat):
#echo off
echo "Hello 1"
REM Configure this to your installation of maven.
SET "CMD=C:\foo.ps1"
REM Reformat args to be Powershell friendly.
SET "ARGS=%*"
SET "ARGS=%ARGS: =' '%"
PowerShell.Exe -Command "%CMD%" '%ARGS%'
echo "Hello 2"
EXIT /B
In cmd, I see "Hello 1", the output of %CMD%, and "Hello 2". In Eclipse, I see "Hello 1", the output of %CMD%, and then it hangs in the progress tab forever until I click the Console window and press the enter key.
I tried passing the -NonInteractive flag to Powershell. I tried having my Powershell script echo a newline at the end. Not sure how to get this to "just work".
Found the answer. I needed to add a NUL redirect to the end of my Powershell command. So it looks like this:
#echo off
REM Configure this to your installation of maven.
SET "CMD=C:\foo.ps1"
REM Reformat args to be Powershell friendly.
SET "ARGS=%*"
SET "ARGS=%ARGS: =' '%"
PowerShell.Exe -Command "%CMD%" '%ARGS%' < NUL
Note that I also removed the dubugging code from the script found in my question. If you add that code back in, you'll see that it echos everything now.

Windows Shell. Restoring Orig Files

After a quick google search I found this link: Mercurial: simple way to revert .orig files?, with the following line of code in the comment:
for /f %i in ('dir /s /b *.orig') do #copy %i %~dpni
In powershell, I tried running it, but I got the following error: Missing opening ( after kyeword for.
Is powershell not the correct way to run this code or is the syntax incorrect?
I am trying to revert my orig files back to their original version (get rid of the .orig extension). I am using windows so BASH is not an easy option.
The comment that snippet came from suggests that the environment you can run that line in is the "Windows command prompt with Command Extensions."
You can create that environment like so: cmd /e:on. It didn't seem like using powershell was the intention, but you could type cmd /e:on into the powershell console and get that environment.
PS C:\> cmd /e:on
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\> Command Prompt Input is Valid Here
You received that error because that syntax is incorrect for powershell -- for statements expect parameters in parenthesis. It should work once you're in the appropriate shell, though.

Windows Scheduled task succeeds but returns result 0x1

I have a scheduled task on a Windows 2008 R2 server. The task includes a Start In directory entry. The task runs, and the batch file it runs does what it is supposed to do. When I run the batch file from a command prompt, I see no errors. The problem is that the "Last run result" is 0x1 (incorrect function call).
I did get this at one time with an incorrect DOS statement IF EXISTS file.txt DO (Copy file.txt file1.txt) that was corrected by dropping the DO statement. The current batch file does not show me any errors or warnings.
Why am I getting a 0x1 result?
Batch file that is run:
PUSHD \\JUKEBOX4\Archives\CallRecording
REM only move csv and wma together. wma should be created last.
IF NOT EXIST C:\CallRecording (MKDIR C:\CallRecording)
FOR /f %%f IN ('DIR /b *.wma') DO (
IF EXIST %%~nf.csv (MOVE /Y %%~nf.* C:\CallRecording\)
)
POPD
CD /D "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload"
CollybusUpload.exe
POPD
Info on scheduled task setup:
Program to run: C:\Program Files (x86)\Olim, LLC\Collybus DR Upload\CallRecordingUploadFromH.cmd
Start in: C:\Program Files (x86)\Olim, LLC\Collybus DR Upload
Run whether user is logged on or not, highest privileges.
History screen, task completed entry
"Task Scheduler successfully completed task "\Call recording upload to portal from NH" , instance "{1449ad42-2210-427a-bd69-2c15e35340e6}" , action "C:\Windows\SYSTEM32\cmd.exe" with return code 1."
First screen of Task Scheduler shows "Run Result" of "Success"
It seems many users are having issues with this. Here are some fixes:
Right click on your task > "Properties" > "Actions" > "Edit" |
Put ONLY the file name under 'Program/Script', no quotes and ONLY the directory under 'Start in' as described, again no quotes.
Right click on your task > "Properties" > "General"
| Test with any/all of the following:
"Run with highest privileges" (test both options)
"Run wheter user is logged on or not" (test both options)
Check that "Configure for" is set to your machine's OS version
Make sure the user account running the program has the right permissions
I found that I have ticked "Run whether user is logged on or not" and it returns a silent failure.
When I changed tick "Run only when user is logged on" instead it works for me.
I've had the same problem. It is just a batch-file, working when manually started, but not working as a scheduled task.
there were drive-letters in the batch-file like this:
put z:\folder\file.ext
seems like you should not use drive-letters, they are bound to the user, who created them - for me this little change made it work again:
put \\server\folder\file.ext
For Powershell scripts
I have seen this problem multiple times while scheduling Powershell scripts with parameters on multiple Windows servers.
The solution has always been to use the -File parameter:
Under "Actions" --> "Program / Script" Type: "Powershell"
Under "Add arguments", instead of just typeing "C:/script/test.ps1" use -File "C:/script/test.ps1"
Happy scheduling!
Windows Task scheduler (Windows server 2008r2)
Same error for me (last run result: 0x1)
Tabs
Action: remove quotes/double-quotes in
program/script
and
start in
even if there is spaces in the path name...
General:
Run with highest privileges
and
configure for your OS...
Now it work!
last run result: The operation completed successfully
Probably not the cause of the OP's problem; for me the problem was caused by the fact that my program called a SQL function, and the service account the windows task was set up with did not have the required SQL permissions. That also gives a 0x1
This answer was originally edited into the question by the asker.
The problem was that the batch file WAS throwing a silent error. The final POPD was doing no work and was incorrectly called with no opening PUSHD.
Broken code:
CD /D "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload" CALL CollybusUpload.exe POPD
Correct code:
PUSHD "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload" CALL CollybusUpload.exe POPD
In my case it was an encoding issue. We wanted to start en existing batch file, and it resulted in "return code 1", and the desired action wasn't performed. I've accidentally found that the batch file was shown in Notepad as one with UTF-8 encoding (actually without any reason, as we have no special characters in the text). I saved it as ANSI, and it solved the problem for us. Might be, that it was a kind of encoding corruption in the file that prohibited Task Scheduler and cmd.exe to open the file, although it was displayed correctly in Notepad.
On our servers it was a problem with the system path. After upgrading PHP runtime (using installation directory whose name includes version number) and updating the path in system variable PATH we were getting status 0x1. System restart corrected the issue. Restarting Task Manager service might have done it, too.
I was running a PowerShell script into the task scheduller but i forgot to enable the execution-policy to unrestricted, in an elevated PowerShell console:
Set-ExecutionPolicy Unrestricted
After that, the error disappeared (0x1).
Just had the same problem here. In my case, the bat files had space " "
After getting rid of spaces from filename and change into underscore, bat file worked
sample before it wont start
"x:\Update & pull.bat"
after rename
"x:\Update_and_pull.bat"
For me the problem was the PowerShell script being ran had #Requires -RunAsAdministrator at the top, meaning it needs to run in an elevated command prompt as an Admin, but the user the Scheduled Task was set to run as wasn't an admin on the local computer. So even though Run with highest privileges was checked in the scheduled task, I still had to make the user an Administrator on the computer. Once I did that, the script ran as expected.
Since there is always more than one reason this could happen I thought I'd share some troubleshooting tips that helped me diagnose my issue.
Always adding a "start in" parameter first since thats an easy fix, even just adding the drive letter can help, e.g. C:\
If you're running "whether user is logged on or not" and it is failing it might be an issue with your user and/or user environment.
Switch the task to run only when user is logged in temporarily for
troubleshooting purposes.
Make sure you're actually logged in AS the user you're telling the task
to run as. (PATH and other environment variables are different by user
and if you see the task running on one user successfully that doesn't
necessarily mean it will run successfully for another user even if they're in the same security group.)
Add pauses or some other type of debugging to your script to give you
time to see any errors that may pop up.
Perform a manual run from the task scheduler window.
Fix any errors you see from your debugging statements. Rinse and repeat.
If it runs successfully switch back to run "whether user is logged on
or not" and try another manual run. If it works now you're all set.
If nothing has helped so far you might need to dig in deeper to your user and file privileges. My troubleshooting tips assume that you have been able to get a past task running using a specific user login already. They don't cover building a scheduled task from a fresh install necessarily. Luckily I haven't had to do that.
What solved it for me was that I was using a local administrator account instead of the domain account so I changed the "Run as" to the domain account.
It turns out that a FTP download call using winscp as last thing to do in the batch caused the problem. After inserting the echo command it works fine. Guess the problems source could be the winscp.exe which do not correctly report the end of the current task to the OS.
del "C:\_ftpcrawler\Account Export.csv" /S /Q
"C:\Program Files (x86)\WinSCP\WinSCP.exe" /console /script="C:\_isource\scripte\data.txt"
echo Download ausgeführt am %date%%time% >> C:\_isource\scripte\data.log

automating windows driver builds

We have a printer driver that we need to build for all OS's from Windows XP to Windows 8, both x86 and x64 versions. I can do this manually using the WDK free build environments, but I need to automate the process - start a batch script and have all my builds ready.
Does anyone know how to do this?
Command-line windows for x86/x64 Debug/Release and various OS platforms differ only in enviroment variables. The scripts setting the environment variables are already available in DDK or Visual Studio. (To find out script names check properties of corrseponding command window shortcuts.) So the problem comes down to writing a Windows batch file setting environment variables and invoking build commands one by one. Most likely environment variables for each next platform overwrite ones from previous platform, but to be safe you can start each build in a separate clean cmd.exe process. Here is the main script:
start /W "cmd /C build_winxp_x86_debug.cmd"
start /W "cmd /C build_winxp_x64_debug.cmd"
...
start /W "cmd /C build_win8_x86.cmd"
start /W "cmd /C build_win8_x64.cmd"
Start /w waits for spawned cmd.exe process termination before executing the next line. Cmd /c terminates when corresponding build script completes.
Example of build script:
#rem Script setting environment variables from DDK
ddkpath\setenv.bat XP x86 dbg
#rem your build commands
cd your_driver_dir
build -cz