Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sraymond]

I use UNC paths to specify filenames - this let's me use the same library on many different machines.

BUT...  MC isn't "smart enough" to recognize that the UNC and DriveLetter path may actually be one and the same file.  And this causes problems when importing.

For example, I may have "\\workstation1\c$\music\song1.mp3" in the MC library.  If I do an import of the directory "C:\music", MC will find song1.mp3 and consider it a new item.  Now I've got two library entries for the same item.

The problem is that I don't always remember to search for imports based on the UNC path, because for some items it's not needed.  And, unfortunately, when I browse to a directory, it's always the DriveLetter path.  So it's quite easy to "forget" to change the "C:\" to "\\workstation1\c$\" before starting the import.

Is this a bug?

Scott-

[Matt]

There are three possible ways to talk about the same file:

1) c:\1.mp3 (local)
2) z:\1.mp3 (mapped drive)
3) \\Computer Name\\1.mp3 (share)

To the best of my knowledge the OS provides no easy way of resolving to one of the three standards above.  You can reduce the list to just 1 and 3 but then there's no easy way to reduce it further.

This means the only way for us to catch this is to go through every file in the database and do a "are you the same" check using file sizes, times, etc. which would be too slow.

If people know some tricks we don't, please let us know.

Thanks!

[RhinoBanga]

Matt,

As an idea off the top of my head why not try looking at the PIDL of the file:

http://support.microsoft.com/support/kb/articles/Q132/7/50.asp


Although I must agree that it's simpler to have a common shared drive across all machines which is what I have.

[sraymond]

Matt,

Perhpas I'm a bit ignorant in this area...  but I thought the whole point behind UNC (Universal Naming Convention) was that you didn't have to know the physical storage device a particular file is on.  So I'd think there are ways to convert between the two.

Surely the programming language has a method for getting the UNC path from a local or mapped path?  Or maybe MC can always use the UNC path *internally*.

3) \\Computer Name\\1.mp3 (share)

I thought the template of a UNC path was \\servername\sharename\path\filename.

Scott-

[sraymond]

In the .NET framework, for example, here's some gouge on converting local file paths to UNC paths.

http://www.codeproject.com/csharp/networkshares.asp

Scott-

P.S.  Please excuse my ignorance of I'm way off base.  Just trying to help.

[RhinoBanga]

But the problem is that you can have two UNC names both pointing to the same file:

\\machine\share1\path1\file1
\\machine\share2_which_is_path1\file1

[sraymond]

But the problem is that you can have two UNC names both pointing to the same file:

\\machine\share1\path1\file1
\\machine\share2_which_is_path1\file1

OK.  But you'd really have to go out of your way to make something like this cause problems.  The original confusion arises from a local path and a single UNC path (there being only one share name to access the local drive - for example, the default hidden share such as c$, d$, etc.)  My premise is that these are readily identifiable as pointing to one and the same file.

Scott-

[Matt]

Thanks guys.

The problem is that on import we just ask the database engine "hey, is this filename in there?"

Asking, "hey, is this PIDL in there?" would be really slow. (unless we switched to only use PIDLs internally but that would cause other problems and be a lot of changes)

Some way to convert a filename to its one "true" filename would be the best.

So you have:

Mapped
UNC
Local

using WInet we can reduce it to:

UNC
Local

But if the UNC is a share that's really a local file, we can't figure that out.  The only ways I've seen to convert a share to a local filename is to load all the shares from the registry but it's OS specific and ugly.

Does that make any sense?  Any more ideas?

[RhinoBanga]

But you'd really have to go out of your way to make something like this cause problems.

Not at all.   With network shares it is quite common for directories to overlap, especially in multi-user environments and with machines that use junction points (the NT equivalent of unix symbolic links).   For example I have my music located at "D:\My Music" but I have junction points in:

C:\My Music
C:\My Document\My Music
E:\My Music


So I can quickly get to my music without all that pesky file navigation.


But from MC's point of view why implement something that would only solve your situation and not mine?   Why not fix it so that it works in every situation.

[RhinoBanga]

Asking, "hey, is this PIDL in there?" would be really slow. (unless we switched to only use PIDLs internally but that would cause other problems and be a lot of changes)

But it'd be quicker than getting the file size, time, etc.

But if the UNC is a share that's really a local file, we can't figure that out.  The only ways I've seen to convert a share to a local filename is to load all the shares from the registry but it's OS specific and ugly.

Plus that wouldn't solve the situation with junction points.

[sraymond]

But you'd really have to go out of your way to make something like this cause problems.

Not at all.   With network shares it is quite common for directories to overlap, especially in multi-user environments and with machines that use junction points (the NT equivalent of unix symbolic links).   For example I have my music located at "D:\My Music" but I have junction points in:

What I meant was that you had to actively create this scenario...  I was originally referring to the case where a user was using the default hidden shares to access files in a networked environment (i.e. with WinXP).

But from MC's point of view why implement something that would only solve your situation and not mine?   Why not fix it so that it works in every situation.

You'll get *no* argument from me here!  But if there isn't a fix for every situation, I'd still prefer a partial fix.

Scott-