Hi there,

Given two file names in relative or absolute format, I need to determine if
they point to the same file. While I can simply pass each to
"Path.GetFullPath()" and compare the results, what is the rule regarding
case. That is, how do you determine whether the local file system is
case-sensitive or not. I don't want to assume that Windows is the target OS
even though realistically it will be. Thanks.

Windows File System is non-case-sensitive. Unix and some others are
case-sensitive.

Show quoteHide quote

Thanks. I'm trying to find the appropriate .NET function that tells me that
however.

On Mon, 30 Apr 2007 10:21:06 -0700, Mark Chambers <no_spam@_nospam.com> 
wrote:

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.

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.  You goal sounds like something you 
should only be trying if it's not 100% important that you always get the 
right answer.

Pete

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)

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).

It isn't 100% important fortunately. However, case-sensitivity is something
I'd like to factor into the equation.

Thanks for your feedback.

On Mon, 30 Apr 2007 18:48:42 -0700, Mark Chambers <no_spam@_nospam.com> 
wrote:

Well, that's just it.  The system you're running on is not necessarily the 
system the file lives on, nor is it necessarily the case that the system 
you're running on supports only one kind of file system.  You can't tell 
just from looking at a string what kind of file system the file resides 
on.  You'll have to actually access the file directly, or at least its 
storage location, in order to know for sure what the file naming rules for 
the file are.

Pete

What you're saying has merit but they're not practical issues to begin with.
Clearly you can't concern yourself with files that don't reside on the same
system for instance. Even on the same machine however, you can be dealing
with a UNC name or other mapping system so that "C:\Whatever\MyFile" and
"\\MyMachine\Test\MyFile" are really the same physical file. You may or may
not be able to determine this however depending on the system or simply
because your access rights prevent it (i.e., you may not have the rights to
call the appropriate function to unravel things). Accessing the file itself
in some way may not be possible either if you lack sufficient rights. As for
systems supporting multiple file systems, this is usually less of an issue
because you'll usually be dealing with one system only and/or you can
typically map from one to the other (if you have the rights). Even under
Windows, using NTFS or FAT with short an/or long names, you can determine if
two files are the same with minimal effort. Ultimately however, the final
arbiter of what you can or can't determine is the system itself. No function
in a generic platform like .NET can ever hope to circumvent this (or deal
with all possible situations). You're therefore forced to be both realistic
and practical about things. Relying on "Path.GetFullPath()" or some other
function (since the latter does require rights if the file exists) and then
comparing the names, is really the only "generic" method at your disposal.
It's not perfect but will realistically handle most cases for whatever file
naming convention is in effect on the local system. Case-sensitivity should
therefore be factored into the equation IMO.

To be honest I dont think there is one.

Not one that I have ever seen.

Since the Microsoft DotNet framework is really for use on Windows machines I
think that it is assumed that they are not case sensitive.

Show quoteHide quote

Thanks for the feedback. In practice you're right, .NET is really for
Windows at this point in time but I don't think it should be treated that
way. It's a generic platform so no assumptions should be made about the
underlying OS IMO, especially if your program or its descendants might still
be around in 10 years.

Show quote Hide quote While I agree I would like to point out that, while the concept of the
framework itself is to be cross platform, the released version at this point
is really only for Windows and they (MS) Have not really added anything yet
that indicates it is truly cross platform. There are bits that allow cross
platform communications (serialization and such) but the framework itself is
Windows.



Looking for cross platform perhaps a look at the Mono project source code
would shed some light.



Perhaps this is an opening for you to write a cross platform library that
returns this information :)

I would argue with you and say that the windows file system, NTFS as it is,
is in fact case sensitive. It's win32 that is case insensitive.

Regards
Kjetil Kristoffer Solberg


Show quoteHide quote

System.Speech
On Adobe's Flash & Flex in ASP.NET
how to avoid inlining?
why use .net?
XmlNode.InnerXml and Xml Readers / XmlDocument