Why I am not in favor of a FileSystemInfo.Compare method

My sense of temporal logistics is pretty skewed compared to everyone else's. :-)

He was referring to this post, which was from last October, and the question that he was asking:

In <3 weeks, there's not going to be the big gulf between managed & unmanged code (I'm talking about VS2005 & C++/CLI).

So if you show us the unofficial 100% correct "static int Compare(FileSystemInfo a, FileSystemInfo b)" in managed code, it will soon be fairly straight-forward to use it from unmanaged code.

(Of course, this assumes that you're OK doing such a thing...there may be other reasons for staying completely in unmanaged code).

Yes, I realize Whidbey is frozen harder than the Antarctic ice pack…I thought the "static" function taking two arguments made things clear; I guess not. Sorry.

Show us the exact C# code for your FileNameCompare() utility function; that way there can be no confusion as to the proper technique. My preference would be to take stronger-typed FileSystemInfo parameters (rather than just strings)…and also to indicate that eventually such code should perhaps be part of that class.

I probably would have taken after Triumph the Insult Comic Dog and said that Whidbey was frozen colder than an Iditarod huky's nutsack, but that is neither here nor there, he was right in any case. :-)

The reason why I am troubled about the development architecture path that leads to a

static int Compare(FileSystemInfo a, FileSystemInfo b)

is that the FileSystemInfo class is of course just a base class for the FileInfo and DirectoryInfo classes, which contains a lot of information:

• the FileAttributes of the file or directory (archived, compressed, etc. -- look at the FileAttributes Enumeration for more details);
• the full path and the originally specified path;
• the creation time;
• the last accessed time;
• the last written time;
• the name (which gives just the last piece of a directory or a file rather than the full path to it);
• Whether the file or directory exists.

Given the level of complexity inherent in these objects, the exact definition of a meaningful comparison between two FileSystemInfo objects is far from clear -- in any given situation, a developer could clearly be expecting it to mean any of these things, and not all of those varied and sometimes conflicting definitions are very farfetched!

However, the fact that the OrdinalIgnoreCase semantic is a 100% match for what many of the methods and functions that make use of the NTFS/FAT filesystems it itself clear (to anyone who reads this blog? <grin>), and it really is comparing the file names (which are in fact strings), not FileSystemInfo objects, which are something else entirely.

Which is not to say that no one would ever add such a method; it happens all the time over in the Windows Shell -- it is why the Shell Lightweight API has so many wrappers around our stuff!

But this leasd (unfortunately) to another, more insidious, problem:

And there are theoretical benefits to such a method if the various underlying filesystems exposed their actual comparison semantics such that one could wrap up the case sensitive nature of CDFS and the case insensitive nature of NTFS/FAT32/FAT and all of the other various differences.

The problem there is that the information is simply not exposed and until it is, the only way to do such tests with 100% accuracy is to create the file, which is not always possible for a myruad of reasons related to permissions and media.

And what happens when you have multiple media forms connected in a single path via symbolic links? In such cases support in the underlying file systems is crucial -- since there is NO ONE TEST that would suffice.

I had high hopes that I could convince Kevin Phaup to require such a comparison method when he was still at Microsoft and that he could convince the people in charge of the various drivers. But now he is no longer at Microsoft and there is no one on that side of the company who I can say I have gone to a party with, or seen their house. Which for some reasons dashes my hopes a bit.... :-(

But anyway, these are but a few of the reasons why the direction of a FileSystemInfo wrapper to handle comparison is something that I am highly resistant to.