BUGBUG: poor title : microsoft

DST 2007 issues in SourceSafe

Richard Berg — Mon, 29 Jan 2007 23:37:06 GMT

The rules for U.S. daylight savings time are changing in 2007. SourceSafe cares about time zones, so you should too. Complete details are in KB article 931804. To quote one section heading, "If you do not update the servers and client computers, you may lose check-in information".

There, do I have your attention now? :)

[Thanks to everyone who helped put this article together. People inside & outside of MS often complain about the difficulty of maintaining the KB -- rightfully so in some cases. This article went from idea to the web in under a week, so it can be done!]

Tidbits: life under a Limited User Account (LUA)

Richard Berg — Sat, 16 Dec 2006 03:29:49 GMT

I'm about to wipe my main work machine and install Vista RTM x64. Wish me luck. Sure, people @ MS wipe their boxen all the time, but I'm not one of them: this install of Win2k3 has lasted me since 6/29/2005. (For reference, I was hired in April '05 and received this machine in early June. So other than a couple months with the noisy old Athlon MP that our office hands from incoming sucker to sucker, and a couple weeks testing the x64 waters when this shiny machine arrived, this install has spanned my entire career.)

Furthermore, I probably have the least Vista experience in the whole company. Despite endless exhortations, I only installed it on my test box after RTM. Adoption drivers, if you're reading: blame the lack of upgrade path from Win2k3 + the fact our Raleigh boot server is not WDS capable. For home dogfooding, meanwhile, blame IHVs: can't upgrade any of those machines until the Emu 1212M, nVidia DualTV, and 3ware 7000 series are onboard, respectively. Much as I cling to long-running software installs (the opposite of every other PC enthusiast, it seems), I swear it wasn't fear: I absorbed Office 2007 releases as early & often as possible and never looked back.*

Sure I saw several Beta1+ Vistas during major Whidbey test passes -- QA uses scores of lab machines to exercise configuration combos. Conclusion: Vista's impact on my scenarios was far lower than most other variables in the support matrix. Whatever people say about the Vista interface, it's way easier for a newbie to navigate than Arabic WinXP or Japanese TFS are. But that phase of my career ended several months ago, just as Vista was really coming to life. Owning SourceSafe is a much bigger responsibility, yet it's also been an escape from the usual DevDiv overhead. So come fall '06, still no quality time with Vista.

*with one exception I'll blog about some other time

----

This post was supposed to detail a few LUA issues I debugged in my first few days of living with a Vista test box, plus complete the final "draft" article sitting in Live Writer so it wouldn't be lost in the main box's wipe. So far I've done neither. Onward!

UAC prompts weren't pre-filling the admin account's username. When you're first setting up a box, you inevitably hit UAC a lot; typing "machineName\adminName" each time was getting old quickly. (No, logging in as the local admin wouldn't help; that would have me typing my domain credentials instead, just as frequently.) My previous experiences with UAC were brief, but I knew it wasn't that annoying. I searched & searched for an answer...my complaint to the UAC talk alias was nearly composed when I finally found this post. Thank you, Daniel!
I type things like "{pushd | start | dir} \\someMachine\d$\<tab complete...>" a LOT. Always will, at least until James gets me fully hooked on PowerShell. You probably see where this is going: when your main network account isn't an administrator on someMachine, admin shares stop working. It's not hard to add some trivially named shares and lose the '$', but it adds conscious thought to commands that used to be rote. Oh well.
Soon as I set up FolderShare, it was stymied. I didn't save the exact error message but it was along the lines of "FolderShare could not write to c:\program files\sync\foo\foo.exe. Retry | Close" First of all, how annoying is it that the only workaround is to close FolderShare? Can't you just disable that library? So begins the only true debugging challenge.

We all know non-admins can't write to Program Files, so step 1 was to grant Modify permission to the Users group on Program Files\Sync.** Click Retry. No dice.
I notice my account is not actually a member of Users, but of Remote Desktop Users. I try manually adding myself to Users as well. (if that fixed it, i.e. RD Users didn't inherit User permissions, I would have to yell at someone!) Somewhere in here I also discover the new Effective Permissions tab in the shell. Very nice...and confirms that this is not the problem. Retry fails again.
Time for Process Monitor. Since FolderShare hasn't been able to drop my toolset into place yet, I manually download it to Program Files\Sync\SysInternals\procmon.exe. Before I can fire it up, though, I notice that accevent32.exe, accexplorer32.exe, etc. are starting to appear in the folder I just created! I manually create another folder under Sync, and sure enough files (but no subfolders) start being pushed there too.
Armed with the theory that I've somehow granted a set of ACLs that allows new files but not new folders, I head back to my elevated shell and give my user Full Control + ownership. Doesn't help.
So, I need ProcMon after all. Filtering on foldershare.exe and the Sync dir, I see that among a sea of successful Querys that CreateFile attempts on Sync's subfolders come back as REPARSE, but there are no actual failures in sight. Mysterious. I know all about NTFS reparse points, but that sequence of calls & return values tells me nothing. Luckily ProcMon has an awesome feature that displays the full stack of each filesystem call. This quickly tells me that foldershare is actually calling RenameFile(), not CreateFile(). Thus, the piece of activity I'm looking at is actually the behavior of an internal Windows function. Furthermore, it's now obvious what's happening (or failing to happen): FolderShare must download to a temp location and then move completed items into place. Still, why would moving from A to B require any more permissions than creating something at B?
Regardless, I know I must remove my path filter. It's ugly -- as I knew from past experience, an unfiltered FolderShare loves to fill up ProcMon logs with hundreds of thousands of entries. But I know what I'm looking for: some sort of anomaly around creating + moving temp files. I soon find it when I spot activity not only under the expected c:\foldersharetemp, but under c:\Users\me\AppData\Local\VirtualStore. Hooray for the vastly simplified name of these directories! But what is VirtualStore? Quick Google tells me it's the root for filesystem redirection: something I'd experienced firsthand in my testing around WOW64, and that I'd read would be used for lots of shimming in Vista, but had not really put 2 & 2 together. I'm also quickly reminded that shimming can be turned off by providing a manifest for your binaries.
So, what does a manifest for a native app look like anyway? Web searches lead me to tons of pages telling me how to add manifests to the Visual Studio build process, a few pages describing the schema for manifests on managed code, but precious little on native code. Surely the format whose root XML node is "assembly" is for managed code only, right? Sadly, the web offers no alternatives, so I copy/paste a sample anyway & restart Foldershare.
Won't load. Syntax error or wrong schema entirely? The event log won't tell me, so all I can do is optimistically eyeball the syntax and try again. Before long Foldershare loads and happily starts writing to Program Files\Sync. Success! So yes, fair web travelers: those manifest samples full of tags like <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="Sample" type="win32" /> really do apply to native code.

**this is where I store apps that don't require installation, making them perfect for FolderSharing. Command line tools, sysinternals, dozens of A/V applets, and lots of misc cool stuff. This category of apps also tends to be freeware or open source, which lead to frequent updates. Finally, a lot of them write user data to their containing folder, either because they're cross-platform or simply amateurish. Thus ends my justification for breaking the principle of least privilege.

Wow. This became a heckuva long post, especially for the offtopic category. Despite my earlier self-deprecation the fact is I'm not ignorant of MS tech trends, especially relative to the huge non-Softie world out there. I knew upfront my first few days under LUA would present trials, yet more than once I found myself wishing the causes & solutions were easier to find. I do know our published info & general transparency is better than it's ever been, and will continue to improve. Novel length or not, I sincerely hope blogging my experiences adds to that momentum in some small way.

Soon as I publish, my next move will literally be Start -> Shut Down, rebooting onto a DVD and into a brave new world. Farewell, dear c:\. See ya on the other side.

When your feature hits the blogosphere: SCM and the Windows Shutdown crapfest

Richard Berg — Fri, 01 Dec 2006 18:23:06 GMT

Moishe Lettvin has a great blog entry, an inside look at how a Vista feature ate thousands of man-hours on its way to the lowest common denominator. I don't mind the UI myself (and certainly won't justify Joel's histrionics with a link) but it does illustrate several common pitfalls in large-scale software development.

Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.

Well, branch integration was my feature. While my job focused more on finding bugs than architecture, you can't own branching & merging at Microsoft without learning a lot about the broader topic of Source Configuration Management (SCM). So I too feel tied to this debate, albeit for a very different reason.

The comments and trackbacks show lots of people dumbfounded at Vista's SCM practices, and not in a good way. Sorry folks -- there are plenty of things from Vista's ship cycle to complain about, but their branch strategy isn't one of them. Granularity in your source control is important for large teams, and protecting the integrity of the root with intermediate stages is even more important. Feel free to argue that the quality gates were too bureaucratic or the integration schedule too random, but they (finally) got the fundamentals right.

Could the particulars of this situation be improved? Sure. As one commenter noted, active development & testing should've been able to happen closer & closer to the root as the feature matured. Even more clearly, the teamwork between dependent feature groups left something to be desired. Much of that is political. And given everything Moishe described I don't think they could've avoiding RI/FI delays entirely. Still, the leadership should've been more willing to create "interdisciplinary" branches for features that were obviously interwoven. (I'm happy to say DevDiv is pioneering this.)

An introduction, 1350 posts later

Richard Berg — Tue, 17 Oct 2006 10:23:07 GMT

On the Microsoft forums, that is...no, I didn't suddenly eclipse Raymond. As you probably haven't noticed, this blog has lain dormant for 18 months. (if blog with no readers falls by the wayside, does it make a sound?) Meanwhile, the last 11 months have seen a wild experiment in direct customer interaction. If you have a question about TFS version control, Team Foundation in general, or Visual SourceSafe, odds are good I'll be the one to answer it. Or even more likely, I already have.

It's the latter conclusion that leads me back to blogging. As rewarding as it is to answer day-to-day questions and bring that perspective back to the product design table, it's not terribly efficient. Fortunately several coworkers have done a fabulous job collecting the most common answers; I link them every day. At the same time, it's the nature of online FAQs to become either too narrow (a single Buck post) or too shallow (Jim's "official" page). On the forum itself, I will often provide some theoretical context, but I never feel like it's a welcome diversion from a customer's very real need to resolve a specific issue, nor is it very discoverable after the fact. (who searches the forum for conceptual material?)

There's an ulterior motive here. You see, even though I'm kicking off a large-scale exploration of Team Foundation Version Control with this post, I don't actually work on TFVC anymore. A few months ago, I shifted positions from SDET on the TFVC Platform team to 'the SourceSafe guy'. The latter title deserves -- and will get -- its own post, but suffice to say my responsibilities have shifted away from the magical land of tf merge. That means I owe my former teammates a braindump. May as well do it online.

Finally, the new day job requires a lot of nitty-gritty debugging. Cool stuff, sure, but the contrast will make blogging about concepts and design that much more appealing. Not only is TFS architecture spiffy and neat by comparison, but I approached it from a different perspective: while QAs at Microsoft share ownership of the product with devs, they ultimately take the customer's point of view. My exploration may mention tables and queries at some point, but that's not my aim (nor frankly my forte). I'd much rather leave you with a working mental model than a mere English translation of a sproc, much less a one-off workaround.

Ok! Any more intro and I'd be leaving myself a fast-diminishing chance of actually living up to it. Enjoy the exposition...stay tuned for some actual content.