Determining if two paths are the same

[Mark Chambers]

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.

 

[Kevin Spencer]

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

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Mark Chambers]

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

case-sensitive.

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

 

[Peter Duniho]

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

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

 

[Ray Cassick]

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.

 

[Mark Chambers]

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)

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

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.

 

[Mark Chambers]

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.

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.

 

[Peter Duniho]

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)

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

 

[Mark Chambers]

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.

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.

 

[Ray Cassick]

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.

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

 

[Kjetil]

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