[quoted text, click to view] > I don't know of any (though that doesn't mean it doesn't exist). If one
> exists, it seems to me that it would have to be in some component that
> actually accesses the file. Like something that gets all of the file
> properties, or opens the file, or something like that.
I think otherwise actually :) It seems more likely that such a function
would probably be part of some class that provides system-wide info about
the environment or OS itself (or the file system)
[quoted text, click to view] > That said, you should probably keep in mind that because of various ways
> to alias a file, even if the paths are different based on a simple string
> comparison, whether you correctly deal with case-sensitivity or not, you
> could still have false negatives.
Yes you're right. It's possible when comparing a UNC name and an ordinary
file name for instance. Sometimes quirky rules also exist that make the task
harder, such as cases where successive backslashes are accepted by some
functions (the "Path.DirectorySeparatorChar" in .NET actually). I've seen
this using the WinAPI. The actual rules for forming names can get quite
elaborate in fact so it is possible that two strings might not compare equal
yet point to the same file. Unfortunately, there seems to be no
comprehensive function which deals with this so I have no choice but to rely
on "Path.GetFullPath()" (without turning to more complicated and/or esoteric
techniques). In practice however comparing the results of
"Path.GetFullPath()" should effectively handle 99% of the cases in theory.
(which I can live with).
[quoted text, click to view] > You goal sounds like something you should only be trying if it's not 100%
> important that you always get the right answer.
It isn't 100% important fortunately. However, case-sensitivity is something
I'd like to factor into the equation.
Thanks for your feedback.