Ah, the weird, wonderful world of Windows filesystem oddities. As I've mentioned before, I'm currently in the midst of tweaking an existing Windows app so it runs properly on Vista, so I've been forced to remember a bunch of ugly details I'd happily paged out.

A few of my favorites, just off the top of my head:

* If you want to know the access & write times on a file, the value you see depends on how you ask. My theory is that Windows flushes metadata updates to disk on a very lazy, periodic basis, although I don't believe they've ever documented this. GetFileTimes() appears to return the in-memory values, in the disk cache or somewhere, while FindFirstFile/FindNextFile always hits the disk and returns whatever's there. I've seen the two out of sync by up to an hour at times. Naturally there's an obscure registry setting that lets you turn off updating of file access times entirely, and this seems to be the default on Vista. Although again, this is completely undocumented.

* Filenames are not case sensitive, except when they are. There are several ways to get two files in a directory whose names differ only by case: Unix drives shared via Samba, or files created under Services for Unix, or files created with plain old CreateFile() with the FILE_FLAG_POSIX_SEMANTICS option (although the latter doesn't work by default on XP & later). Explorer gets deeply confused when you try to open one of these, and opens whichever comes first alphabetically (I think), regardless of which one you actually clicked on.

* Paths are limited to MAX_PATH (260) characters, except when they aren't. 260 characters too restrictive? Just prepend "\\?\" to your path and away you go, up to around 32000 chars. Except that nearly all Windows apps don't know about this trick either, so you can create directory trees that almost nobody can see into. To be fair, you can do something similar on Unix too. It's easy to write a little program that creates a directory with a long name, chdir's into it, creates a subdirectory with a long name, chdir's into it, and so forth, and do a getcwd() at each iteration. Eventually getcwd() starts failing, but the OS is quite happy to go on creating subdirs for you until you fill up the disk.

* The registry has a different trick for creating keys nobody can see into. The underlying (and little-known) Native API refers to object names with counted strings, not null-terminated ones, so you're free to use embedded null characters in the names of things. Well, some things. I don't think NTFS accepts null chars in names, at least. But the registry's just fine with it. The regular Win32 API everyone uses *does* use null-terminated names, though, so if you create a key with an embedded null in the name, there is simply no way to open it with RegOpenKeyEx(), because its name is basically "unspeakable" as far as Win32 is concerned. MS actually used this trick to secure sensitive bits of the registry, like parts of the local SAM db. Which works great so long as nobody learns the trick. Security through obscurity...

* Vista introduced a new twist on "unspeakable" registry names. There's a new function called RegLoadAppKey(), which promises to give your app its own private chunk of registry nobody else can see. And it's true, you get a bit of registry that can't be located with HKEY_LOCAL_MACHINE, HKEY_USERS, or any of the other predefined keys.

A bit of background is in order here. The NT kernel uses a different path scheme than what people are used to seeing in Regedit, or Explorer for that matter, and the names of things you encounter are not their *true* names. HKEY_LOCAL_MACHINE is really \Registry\Machine, HKEY_USERS is \Registry\Users, C:\ is usually something like \Device\Harddisk0\Partition1, and so forth. I rather like this unified namespace, actually, as it makes things feel just a little more Unix-like. So of course it's completely invisible to end users, with occasional exceptions such as registry audit events.

So the new trick from Redmond is to mount "private" registry hives under \Registry\A\{GUID}, where GUID is newly assigned each time a hive is mounted. Once you know where to look, "private" isn't quite so private anymore. Still, Regedit and other apps using Win32 functions can't see this stuff, so I expect it's only a matter of time before the spyware crowd starts exploiting this "feature".

* Vista now offers symlinks, which are not the same thing as hardlinks, or directory junctions, or shortcuts. Symlinks are implemented as "reparse points", and the symlink data is stored as an alternate data stream. Directory junctions are "reparse points" too. Actually there are at least seven different kinds of reparse point, and counting, and there's a complex API that lets you define your own types too, like you'd really want to do that. Hardlinks are a low-level NTFS feature that's been around since the beginning, although poorly supported until recently. Shortcuts are a higher-level feature, belonging to the UI part of the OS, and are implemented with COM.