Win32 Reparse Points
One of the common challenges that we server admins face at work is, of course, disk space.
Windows and NFTS have some very powerful features built in, but I sometimes get the impression that Microsoft didn't always think how a customer of theirs would actually be able to use those features.
Win32 reparse points fall into this category. They are currently my favorite MS "feature" to rant about at work...
What is a reparse point you ask? Well, the simplest explanation is that it's a file system object that causes the OS to do a bit of extra processing when it runs across one to go somewhere else to get the desired data - insetad of just reading that object directly like a normal file/folder. It parses the file system object a second time, hence the name.
A reparse point works by sending the contents of the reparse point to a file system filter driver, that does the actual processing and spits the results back.
That file system filter can be a MS driver, or a third party driver.
The most common examples of reparse points are junctions and volume mount points.
Other common uses of reparse points are for archival of files. The archival program moves the file off to archival storage location and creates a reparse point where it was. The OS calls the archival program when it encounters the reparse point to go and fetch the actual data. The OS can do that because the archival program registers a GUID with MS for their reparse point type (tag type), and the OS knows to call their filter based on that GUID.
Fun stuff.. the above was a bit of a simplification, but it should be accurate enough.
Junctions and volume mount points concern the average server admin.
A "junction" is a not-so-technical term that means a reparse point for which the target is another folder.
A "volume mount point" means a reparse point for which the target is a volume.
Interestingly, as far as the reparse point goes, there's no difference between a junction and a volume mount point.
The frustrating thing, is that Microsoft built these powerful features into the OS and then didn't bother to include tools to adequately manage them.
This is really bad, because if you're using these features a lot to get around drive letter limitations, drive space limitations, or to make the file system more intelligently laid out, you can end up having more problems from trying to get the security right, not have loops in the backups, etc...
I should point out there are some programs out there for doing some work with reparse points, but they aren't comprehensive to say the least, and most server admins will quickly realize that they can't do things they'd expect to easily be able to do.. such as, oh.. list all the volumes on a server and where they're mounted to.
So what do we do.. well, we learn the API calls and write the tools ourselves!
Look for some entries in the Win32 and Tools section soon about this...
Two "cluster-"s don't make an "un-"
The really frustrating thing is that you can do this and still be assured of a truthful statement:
"The frustrating thing, is that Microsoft built these powerful features into [insert name of MS product] and then didn't bother to include tools to adequately manage them."
Now I'll share one of mine:
"You can tell that MS personnel never actually use [insert name of MS product], because this bug/poorly implemented feature would be just plain intolerable to anyone above 'learner' level." (Or, more cynically, the "...'impressed by reading about it on the product packaging' level")
Yuk yuk!
Anyway, just stopping through on a quest for manageability for reparse points and their constituent data via C#. Your info/code on the subject seems useful and I'm sure I'll be back when I am ready to deal with it in detail.
By the way: only working in C# because I am manipulating NTFS files and seek a little closer OS integration than what I assume I'd get out of some non-native language. Wherever possible, I avoid cruddy, overpriced (, disingenuously hyped, inscrutably named) Microsoft tools anymore.
Yeah, I know C# isn't technically native. But I (foolishly?) expect its IO object model to mirror that of the OS relatively closely vs. Java, Python, etc. So far, so good, actually. All the open source wunderkind languages certainly have their issues, as well, but on the whole, the positives have come to outweigh the negatives. Or maybe their positives are fairly static while MS just keeps piling on more negatives...
All in all, considering I'm spending my time just implementing some functionality that one would expect out of the OS anyway (wow! kinda like your story!), I have to say: FUN STUFF!!
[attempt #2: stupid captchaware doesn't know a verb? I was going to do some fun mad-lib-y stuff with it, but now I'm just irritated. Whoever chose the word "intuitive" to characterize the type of response Egglue will validate has got some nerve!]
RE:
Yeah, i would echo that. Good comments, thanks!
I certainly don't know everything, but let me know if you have any questions.
At least i can say i didn't write the captcha module.... Hard to ballance avoiding spam vs. ease of use.