It looks like this code is not yet functional. I would expect it to show the target path of a junction, similar to how %P would display a normal path.
Ah, ok. Thanks, now it's clear. I assumed, i can be on a junction to show the path, like the "target" columns would.
Is "%G" new? I could not find it in the docs, but I like it. o)
EDIT: Ah, it's in the release notes pdf.
For symbolic links though, which point to network locations, %G shows the volume-id of the remote computer instead of the actual network location linked to.
So I see something like "\?\Volume{aaaaa-bbbbb-ccccc-..-00000}\gfx" instead of "\192.168.0.1\d$\dat\gfx". Is that something which could be supported?
The symlinks I have in use are created with "mklink.exe" (I linked several remote folders (located on storage server) into my local filesystem):
mklink /D gfx \192.168.0.1\d$\dat\gfx
I can't reproduce this here, the title bar shows the UNC path as expected for me. Are you sure you actually created the links with the UNC path and not the \?\Volume... thing?
Uh! I guess this possibly is because the target location is a disk mounted to filesystem, not a regular folder.
So "\192.168.0.1\d$\dat\gfx" is a disk local to 192.168.0.1 mounted there as "D:\dat\gfx" instead of using a drive letter.
The chain is:
(local) D:\dat\gfx --symlinked to--> (remote) \192.168.0.1\d$\dat\gfx --mountpoint for--> (local on remote) \?\Volume{a-b-c-..-0}
Ah ok, that explains it. Opus tries to resolve the full chain of links, including any mountpoints. And if there's no drive letter then it doesn't have a choice - there's nothing else it could resolve the mountpoint to except the GUID path.
Yes, I see. o) Maybe you can break the chain, if the symlink points to a UNC location? Getting down to what is behind that UNC location makes not much sense I guess. If a link is pointing at a UNC location, then this UNC path is fully sufficient and represents the actual information desired. UNC locations resolving to "lettered" drives or local folder paths on remote computers is irritating information, since these locations, volumes and IDs are not relevant for the local computer, to be precise, they are unknown and inaccessible.
Did you change something in 4b?!
The %G does not seem to resolve paths anymore, wether it's local junctions or my remote-endpoint symlinks. Hu? o)
What if the UNC path is a symlink to a third machine?
Good point, I intentionally did not mention this, because I think it's an uncommon scenario. o)
If the UNC endpoint links on to another machine, resolving to that UNC location is nice to have, I would not setup links like this though.
Linking from UNC to UNC probably is more the "accident" case, since you could always link there directly if you really wanted to.
If that is to be supported, the condition to break the chain is different of course. It's not "break" after detecting a UNC target, instead it's break if an UNC link in the chain resolves to a "local" type of location (regular path, letter, volume ID).
Tbh, your scenario is already an uncommon one 
Well.. o) These UNC-symlinks are just not well known to most people, so very few make use of it.
Actually they provide an awesome option to access remote filesystems. Mounting disks to filesystem folders is also something only few people do, but gives great flexibility as well (especially in fail/restore situations). In combination you end up with what we have here. I just use what's built into windows these days. o)
Yes, a bit uncommon. I hope more people get to know this. o) Mapped drives, windows libraries, dynamic disks and specialized tools to create merged filesystems did not work out. Using symlinks across computers seems the only solution which does not come with heavy restrictions on where and how to use. They work fine, even in a DOS prompt. Plz don't be angry with me for using what works. o)
In the next beta we'll stop resolving once we hit a UNC path that resolves to a non-UNC path; I think that should be safe and you're right, resolving local paths on remote machines isn't really that useful.
Happy to hear that! o)
[quote="tbone"]Did you change something in 4b?!
The %G does not seem to resolve paths anymore, wether it's local junctions or my remote-endpoint symlinks. Hu? o)[/quote]
Remote UNC endpoints I linked to with "mklink /D" still don't show when using "Set Listertitle "%G" in beta7. This once worked, but kind of stopped around beta4 it seems?
It works here from a simple test without mount points. Are mount points still involved or do you mean %G isn't doing anything at all now if the target is a UNC path?
In my test, I ran mklink /D TestLink \machine\share$ from a command prompt, and Set LISTERTITLE "%N %G" in the FAYT command field. I then double-clicked TestLink and the title says TestLink [-> \machine\share$.
%G isn't doing anything at all, testing plain UNC only, no mountpoints involved here.
I tried what you tried and it's the same, all I get is "TestLink" in the title if I stick to your example.
Are we both doing the same things?
Yes, absolutely the same.
Now I tried again here at home although it's still beta6 here, but I assume nothing is different in this regard to beta7 which I installed today at work.
Don't know! o) If you have another idea, let me know.
I don't think anything related changed from beta6 to beta7 so don't worry about that.
Could a script be changing the title, so the %G isn't really there?