Now to wait and see if there’s enough “technical” content to make it worth me attending.
My blog feed has been available through FeedBurner for a long time, but I’ve now changed the blog template so that it publicises the FeedBurner feed directly.
If you’ve subscribed to my feed, first of all “Thanks!”
I’d encourage you to update the URL to point to the new feed source. That way if anything changes in the future, you won’t need to worry - it should all just continue to work.
I’m preparing to re-install my workstation and go from Vista RC2 to the RTM version, now that we’ve got access to the volume license versions. As they are only “Upgrade” versions, I’m planning to try this workaround to achieve a clean install without having to install XP first.
When I installed RC2, I didn’t re-partition the disk - I just left it as one big C: drive. This has now come back to haunt me, as it means in order to to a clean install of the new OS, I’ve got to move everything that I want to keep onto an external disk, and then copy it all back when the new OS is up and running. Previous machines have always had two drives, so didn’t used to be such a problem.
I’ve created a batch file to run robocopy.exe (which is actually included in Vista now), so I can select which folders I want to backup to the external disk.
That all worked fine until I pointed robocopy at my profile folder.
Your profile is located in %USERPROFILE% in case you were wondering - on a clean install of Vista, that maps to a folder under C:\Users. The old “C:\Documents and Settings” as used by XP is still there, but it redirects to the new folder.
This is related to where things went wrong. The way Vista does the redirect is by using Junction Points - they’re kind of like symbolic links in Unix. The trouble is that Junction Points are also used inside your profile folder to redirect from the old name (eg. “Application Data” to the new name “AppData”).
I wondered why robocopy was taking so long, and then looked at what it was doing - it seemed to be copying the same files over and over again - and then I realised that’s exactly what it was doing - it was stuck in a recursive loop because it kept hitting a junction point that took it one directory deeper each time. Eek!
So I stopped the batch file, but now I needed to remove the mess on the external disk. This handy batch file did the trick - curiously it also relies on robocopy to remove a directory heirarchy that suffers from “the path is too long” errors.
I’m now using an extra argument “/xj” with robocopy to tell it to ignore junction points and it should all be fine.
robocopy c:\users\username e:\users\username /mir /r:0 /xj