Simple Folder Synchronization Using XCOPY

There are many times when it is necessary to make sure that one folder stays in synch with another.  The possibilities are endless, but one that I run into a lot is the need to retry copying files to a folder because they were in use when I tried the first time.  For example, I may be deploying a new build of Smart Client software but somebody is in the application so it can not be overwritten on the network. 

In order to combat this, the solution is simple.  Just using the right switches of XCOPY can work pretty smooth.  Here is a quick way to recursively copy all files.


set AttribPromptSwitch=/i/f/s/e/r/h/d/y/z

That one line in a .bat file can be magic if you want to do the same things that I typically do, which is “Make this folder look like that one and don’t ask me any questions!

@echo off
time /t

REM ————————-
REM ————————-
set COPYSOURCE=”C:\temp\SimpleSynch\ThisFolder”
set COPYTARGET=”\\Server\Share\ThatFolder”

del SynchFromThisToThat.logs

set AttribPromptSwitch=/i/f/s/e/r/h/d/y/z

REM ————————-
REM ————————-
echo “Copying from:
echo “to:

REM This is where the actual work is done
xcopy %COPYSOURCE%\*.* %COPYTARGET% %AttribPromptSwitch% >> SynchFromThisToThat.log

time /t


If you want more detail on what each of the switches do, here are a few good references:


Giving TeamCity another try…

Thanks to a comment from Eugene Petrenko, I decided TeamCity was worth another shot.  Everything I have heard has been positive, so I can’t let a little problem like not getting to my source control repository get in the way of continuous integration 🙂

Once again, I visited the TeamCity download site and read all of the fine print once again to figure out what I was missing.  All I can gather right now is that I am going to want to upgrade, but I am not sure yet what the killer feature is that will push me to fork out the credit card digits.

Install was smooth (as it was the first time), but this time I changed the services to run using a domain build account instead of the local system account.  There are 2 services that are installed with the default installation options, and I changed them both to run under this more privileged account:


I was definitely impressed with the ability to test the email settings. It was intuitive and gave me a better feel that things under the hood were put together in a manner consistent with the feedback I have heard about this tool.

Once I got the right user specified in the service it was able to connect to my VSS instance and I am now running my first test build.  Not bad considering it took me about 15 minutes and I couldn’t even tell you where the documentation is located!  I am warming up to this TeamCity stuff….


TeamCity Install Experience

Well, my hopes for a streamlined CruiseControl.NET were not realized in my first attempt at installing the continuous integration server software.  My CCNet lava lamp server died on my last week so I needed to spin up a replacement.  This seemed like a good opportunity.

Although the installation was slick and simple, I feel as though I was more of a user and less of an administrator when I started using it.  I guess that is the idea, but I want to know what is going on with my builds and know how to tweak stuff.  Having that comfort level with an existing toolset leaves me biased, but I digress.ragepost

The big disappointment was the fact that I wasn’t able to even select a VSS source control instance because it kept telling me the file didn’t exist?  Maybe it was because my machine was 64bit.  Maybe it is because VSS support is weak since they think nobody uses it any more.  Maybe it was because the user interface is pretty but not very bulletproof?  Whatever the reason, I am probably not going to be spending any more time on this tool in the immediate future.  Until I can find somebody to help me through a VSS example I’m not sure it will be time well spent…