Page TM 1
The NT Insider The only publication dedicated entirely to Windows® system software development A publication by OSR Open Systems Resources, Inc. Not endorsed by or associated with Microsoft Corporation.
July - August 2010
Writing Filters Is Hard Work: Undocumented DFS & RDR Interactions
he Distributed File System (DFS) is a Microsoft technology that allows for an enterprise to configure a single server with a root share that contains multiple links. To clients, the links appear as regular folders under the root share, however they can point to shares either on the same server system or on any other computer in the organization. For example, you may access a share from your client machine via the path \\DfsServer\DfsRoot\Documents. This could then end up being a link to an e n t i r e l y d i f fe r e n t s e r v e r , s a y \\FooServer\Share. Thus, ignoring the other features and options that DFS provides, DFS is effectively a name aliasing technology that allows an administrator to redirect client requests from one machine to another. Frustratingly, over the years we‘ve regularly run into nagging issues with DFS‘ interaction with the file system filter drivers that we have written. To
the casual observer, one would expect that a file system filter driver writer would care little to nothing about DFS. Aside from the potential aliasing issues that this architecture introduces, which exist in other scenarios anyway, this seems like the sort of thing that should be handled transparently to the client. Unfortunately, due to some architectural and design decisions made in the implementation of XP‘s DFS client support, dealing with DFS can quickly become a hornet‘s nest at the bottom of a rat hole. In addition, the Filter Manager mini-filter abstraction attempts to hide some of the implementation details and in the process complicates things even more. Before we begin, we should note that substantial changes have been made to this space in Vista and thus the discussions in this article only apply to O/S releases prior to Vista unless noted otherwise. (Continued on page 18)
The NT Insider Goes Digital– Good? You are reading the first electronic version of The NT Insider! We’re saving trees, a gazillion dollars in print and mail services and getting the issue into your hands at least 2-3 weeks earlier than the print edition. Does this medium work for you? Why or why not? What can we do better? We want to hear from you! Send comments to [email protected]
Volume 17 Issue 2
WDK Community Bug Bash Contest
t‘s back! After almost ten years since the first ―Bug Bash‖, OSR is back to kickoff a new edition, now the WDK Community Bug Bash Contest. What‘s a Bug Bash Contest? Well, aren‘t you going to be glad you asked. It‘s easy: you find and report bugs in the Windows Driver Kit (WDK). That‘s it. That‘s all you have to do. From there, the bugs will be triaged and reported directly to the Microsoft WDK team—so at a bare minimum, you are helping to get bugs fixed in the WDK. But wait, there‘s more! It wouldn‘t be any fun if we didn‘t run a contest, where every valid bug submission earned a prize, and where all valid bug submissions were judged against one another for eligibility to win one of several really worthwhile grand prizes (if you will). Really, in the end, if you read this publication, the WDK is required for some portion of your job function, and thus improving upon it can only help you. And hey, you could use a iPod touch, an Visual Studio Ultimate with MSDN subscription, or a netbook to play around with, right? For more, see the center page spread on pages 16-17.
The NT Insider™ Published by OSR Open Systems Resources, Inc. 105 Route 101A, Suite 19 Amherst, New Hampshire USA 03031 (v) +1.603.595.6500 (f) +1.603.595.6503 http://www.osr.com Consulting Partners W. Anthony Mason Peter G. Visca