Groups | Blog | Home
all groups > dotnet framework > april 2007 >

dotnet framework : Determining if two paths are the same



Mark Chambers
4/30/2007 10:27:40 AM
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
4/30/2007 12:56:38 PM
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

[quoted text, click to view]

Mark Chambers
4/30/2007 1:21:06 PM
[quoted text, click to view]

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

Peter Duniho
4/30/2007 6:12:54 PM
On Mon, 30 Apr 2007 10:21:06 -0700, Mark Chambers <no_spam@_nospam.com>
[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.

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.

Peter Duniho
4/30/2007 7:16:30 PM
On Mon, 30 Apr 2007 18:48:42 -0700, Mark Chambers <no_spam@_nospam.com>
[quoted text, click to view]

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.

Ray Cassick
4/30/2007 9:17:15 PM
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.

[quoted text, click to view]

Mark Chambers
4/30/2007 9:48:42 PM
[quoted text, click to view]

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]

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]

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
4/30/2007 9:54:02 PM
[quoted text, click to view]

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.

AddThis Social Bookmark Button