INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: UNC Paths Driving Me Crazy... This Is A Bug?  (Read 2440 times)

sraymond

  • Guest
UNC Paths Driving Me Crazy... This Is A Bug?
« on: December 05, 2003, 09:36:16 am »
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-
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42373
  • Shoes gone again!
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #1 on: December 05, 2003, 10:30:06 am »
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!
Logged
Matt Ashland, JRiver Media Center

RhinoBanga

  • Citizen of the Universe
  • *****
  • Posts: 1703
  • Developer
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #2 on: December 05, 2003, 03:23:49 pm »
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.
Logged

sraymond

  • Guest
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #3 on: December 05, 2003, 03:24:53 pm »
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*.

Quote
3) \\Computer Name\\1.mp3 (share)
I thought the template of a UNC path was \\servername\sharename\path\filename.

Scott-
Logged

sraymond

  • Guest
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #4 on: December 05, 2003, 03:30:36 pm »
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.
Logged

RhinoBanga

  • Citizen of the Universe
  • *****
  • Posts: 1703
  • Developer
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #5 on: December 05, 2003, 03:33:10 pm »
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
Logged

sraymond

  • Guest
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #6 on: December 05, 2003, 04:10:46 pm »
Quote from: RhinoBanga on December 05, 2003, 03:33:10 pm
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-
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42373
  • Shoes gone again!
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #7 on: December 06, 2003, 01:49:41 am »
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?
Logged
Matt Ashland, JRiver Media Center

RhinoBanga

  • Citizen of the Universe
  • *****
  • Posts: 1703
  • Developer
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #8 on: December 06, 2003, 01:59:49 am »
Quote
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.
Logged

RhinoBanga

  • Citizen of the Universe
  • *****
  • Posts: 1703
  • Developer
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #9 on: December 06, 2003, 02:07:45 am »
Quote
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.


Quote
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.
Logged

sraymond

  • Guest
Re:UNC Paths Driving Me Crazy... This Is A Bug?
« Reply #10 on: December 06, 2003, 12:18:36 pm »
Quote from: RhinoBanga on December 06, 2003, 01:59:49 am
Quote
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).

Quote from: RhinoBanga on December 06, 2003, 01:59:49 am
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-
Logged
Pages: [1]   Go Up
« previous next »