Do Junction Points still work in Mezzmo?

[Yury]

But if you add a folder with path through junction (ie this folder is not junction itself, and does not contains junction), Mezzmo does not resolve junction, and stores in database original path to the files. In this case all works fine, the server has access to the files, I just tested it.

Example:
"d:\videos\tv" - junction, that points to folder "e:\tv".
Folder "e:\tv" contains subfolder "MyRecords" with file "movie1.mp4".
When I add the folder "d:\videos\tv\MyRecords" (not "d:\videos" and not "d:\videos\tv" !) in Mezzmo library, Mezzmo stores in your database the original path to file: "d:\videos\tv\MyRecords\movie1.mp4", and all works fine!

How can it work, if user junctions are not accessible from the Local System account ?

[Paul]

Hi Yury,

You can change your Mezzmo server from operating in the Local System account to your Windows user account. This will enable it to understand your user-defined mappings, etc. See this FAQ - http://forum.conceiva.com/showthread...r-home-network

[Yury]

Hi Paul.

No need to change the service account, it will not help, because I do not use any user-dependent mappings.
I am only talking about "NTFS junction points" (next I will call it simply "Junction"), which are created by the LINKD utility in Win2003/XP. It is not user-dependent links!

Local System account perfectly sees and understands user-created Junctions, that was what I was trying to show you in my example, but you did not understand me. Maybe here is guilty of my bad English and very very bad online translators
I'll try again.

We have following folder structure:
"d:\videos\tv" - Junction, that points to folder "e:\tv".
Folder "e:\tv" contains the subfolder "MyRecords" which contains the file "movie1.mp4".

(1) Execute the command "Add Folder", as a target specify "d:\videos\tv\MyRecords".
Result: Mezzmo stores in database the original path "d:\videos\tv\MyRecords\movie1.mp4". Service, which running under Local System account, perfectly works with this file (I checked this), despite the fact that this path contains Junction.
It can not be otherwise, since a Junctions are not bound to any user.

(2) Command "Add file" with target "d:\videos\tv\MyRecords\movie1.mp4".
Result: all exactly the same as (1): the same original path recorded in database, service also works perfectly with this file.

(3) Again "Add folder", but with different target: "d:\videos\tv".
Result: Mezzmo resolves the Junction, and now stores absolute path in database: "e:\tv\MyRecords\movie1.mp4"
The same will happen if as a target specify "d:\videos", or "d:", i.e. any folder located above Junction in folder tree.

So what prevents you to store original path in the database in the last case ? In my opinion nothing!

The current implementation more similar to programmers bug: they parse path down through the folder tree, but forgot to do it in upward direction.
I suggest to forget about it for downward direction too , i.e. always store original path in the database. This will kept full functionality of the Junctions, as well as other similar links. The problem of using any user-dependent mappings in this case may be easily solved by running service under user account.

[Paul]

Understand now, Yury. Thanks for the excellent explanation. We'll look into this problem & fix it for a future release.

[JMC]

Any news on this? Noticed today after moving a LOT of files around and creating junctions points that mezzmo spent hours recreating all metadata :/

[Paul]

We'll re-test this for the upcoming Mezzmo v4.0 and make sure it's working.

[JMC]

Fun fact: For some Files it is working, for others not. Inside the same Folder! I have a Folder Documentary and inside files other subfolders. The files in the root use the junction-path, all files inside subfolder 1 use the junction path, all files inside subfolder 2 get re-indexed and got duplicated entrys in the .db (took a look with a sqlite browser)... For a second Top-Folder no files at all use the junction path. So no straight behaivor at all.

Is there any ETA for 4.0?