Paul Beesley

I love the .NET Framework. I mean that purely in a platonic sense, of course - it’s not *that* good. As with all platforms though, it falls down in certain areas. Java has its slightly quirky date APIs and I think one of .NET’s quirks has to be folder handling.

Back in my day…

Like many people, for better or for worse, I started out programming in VB6 around 2003. I’d managed to write some fairly decent programs - decent more in functionality than code quality, I admit. When Visual Studio .NET 2003 came out, I started learning to program in C# on the then relatively young .NET framework. I was having so much fun, in fact, that I asked for Visual C# Standard for my birthday!

Back then, the .NET framework made learning a new language much easier. There was a nice set of standard libraries, automated garbage collection and I found that a lot of the methods I was writing in VB were included as standard in the framework.

Rose-tinted specs

Recently, though, the framework has been getting on my nerves in a pretty big way. Sometimes the way it handles basic operations is odd, unreliable or just downright broken. One such problem is handling folders.

EduSweep, my network sweeper, scans entire drives for unwanted files. The process it uses goes something like this:

• Get the list of targets that the user selected
• For each target, get all the subfolders and make a list of them
• For each folder in the list, scan its files

And that’s pretty much it; it’s not very complex, nor does it need to be. The framework has other ideas, however. By far the simplest way to get all the subfolders of a path would be to use GetDirectories like so:

GetDirectories(“*.*”, System.IO.SearchOption.AllDirectories);

That initially looks fine but let’s assume that we have a folder somewhere on the drive that is inaccessible due to insufficient permissions. A good example is the system folder “System Volume Information” in the root of drive C. The code attempts to get the subfolders for the folder but fails because the directory listing is denied.

We can wrap that code in a try block, catching the exception, but then no results are returned at all! The method is essentially useless because you know that, as soon as it encounters a single folder it can’t access, it throws its toys out of the pram. The only alternative is to manually recurse through the directory tree, enumerating folders and subfolders along the way.

Would it be so hard to skip folders along the way and return a string array of failed directories?