Creating junctions in Windows for Hudson build

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.cor开发者_JS百科e\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