Column: Link2Volume (volume data for links and shortcuts)

Link2Volume - A column set which provides volume data (size, free space, drive letter etc.) for all symbolic links, junctions, mountpoints and shortcuts to local or remote locations like shares, folders, unc-paths, regular volumes, file-system mounted volumes etc.

Description:
As I use mountpoints and symlinks quite a lot, I hooked onto an idea which came up here: Display/treat regular folder as My Computer.
The columns follow any link recursively, so in case you have a shortcut (*.lnk-file) pointing to a junction, which then again points to a mountpoint on a remote machine, you will get all information from the volume on the remote machine, displayed for that locally stored shortcut. I did not try all possible chainings, but it looks very promising. o)

Demo:
Notice, this is not the regular "My Computer" folder.
It is just a regular folder containg all sorts of different link types to a wild mixture of local/remote locations and volumes.



Hint:
To resolve some links "fsutil.exe" and WMI is used. On my system it took some additional firewall rules to allow outgoing WMI connections. If you get an "Access denied" error message in the log (console), it's not necessarily a missing permission on your remote system. In case you have trouble with specific locations, check the log and maybe raise the loglevel to "dump" in the script config.

HowTo:
..create a symbolic link, junction or mountpoint?
Search the web for "mountvol.exe", "mklink.exe", "fsutil.exe" and general windows disk management for instructions and use cases.
DO also allows to create various kind of links with the "Copy MAKELINK" command, refer to the manual for more.

Installation:
To install the columns, download the *.js.txt file below and drag it to Preferences / Toolbars / Scripts.
After that, right click any listers column header and add the columns from the "script" submenu.

Download:

1 Like

Nice :slight_smile:

Thanks! o)

Still some todos left I think:

  • limit resolving of volumes to folders only (disable support for *.lnk files)
  • blacklisting of specific paths
  • localization

Any feedback welcome, especially in terms of performance. For some cases the script queries WMI three times in a row.
Though there is caching for the WMI result built-in, refreshing can still result in some noticeably delays.

Another thing to explore is: Why is there an "Access Denied" for most of the junctions created by windows?
Follwing paths e.g., do not resolve by "fsutil.exe" to their target for me (although DO can):
"C:\Documents and Settings", "C:\Programme"

"Zugriff verweigert" == "Access denied":


Oh, the "Access Denied" thing can easily be cured by editing the security settings on those folders, too obvious! o)
Still wonder why DO is able to resolve those targets, doesn't it run in my users context?

Windows intentionally permissions the hidden+system junctions like "C:\Documents And Settings" in that way.

They exist for backward compatibility with poorly written software (which uses hardcoded paths instead of looking up the paths via the API). The permissions stop tools from accidentally recursing into the junctions, e.g. when backing up or searching data, since it would result in the same things being returned twice, and infinite loops in some cases. The folders are hidden+system so that normal users never see them, and they are best ignored.

You probably shouldn't modify those permissions as they are there to protect against problems.

The permissions do not stop the targets being resolved, which is why Opus is able to. fsutil must be trying to do more than just resolve the target when it fails.

Makes sense! I forgot that these folders are hidden normaly. So, no more security issues, fine! o)
Ok, fsutil.exe works for all other links at least, so whatever it stops it from working on these hidden/system-folders shouldn't really matter. Thanks! o)

This reminded me of a question I had in the past: There's no way to query from script, what DO can fetch for an item in a specific column, right?
Then I could simply use what DO spits out as "Target", instead of making use of an external tool to resolve it.
There really is valuable information in all these DO columns, which is hard to get via scripting alone or even with external helper tools!!! o)

Inside Opus and on Windows I always use:

Copy MAKELINK=softlink

See also: Making Links and Junctions in the manual.

Yes, playful. You can of course make use of the internal DO command to create links! I'll add that to the tiny "HowTo".. o)

I recently decided to go the way of NTFS mount points instead of drive letters and found this script immensely helpful. It seems to be working however it generates some errors in the console which I cannot pin point exactly.

 2017-12-13 13:22 Column.Folder: Link2Volume:  Column_Link2Volume(): [A Elements]
 2017-12-13 13:22 Column.Folder: Link2Volume:  Column_Link2Volume(): [A Elements]
 2017-12-13 13:22 Column.Folder: Link2Volume:  Error at line 251, position 3
 2017-12-13 13:22 Column.Folder: Link2Volume:  Subscript out of range (0x800a0009)
 2017-12-13 13:22 Column.Folder: Link2Volume:      Column_Link2Volume(): [A Elements]
 2017-12-13 13:22 Column.Folder: Link2Volume:  Error at line 251, position 3
 2017-12-13 13:22 Column.Folder: Link2Volume:  Subscript out of range (0x800a0009)
 2017-12-13 13:22 Column.Folder: Link2Volume:          Column_Link2Volume(): [A Elements]
 2017-12-13 13:22 Column.Folder: Link2Volume:  Error at line 251, position 3
 2017-12-13 13:22 Column.Folder: Link2Volume:  Subscript out of range (0x800a0009)
 2017-12-13 13:22 Column.Folder: Link2Volume:              Column_Link2Volume(): [A Elements]

I'm thinking of implementing a global caching mechanism for storing the values indefinitely and only updating on demand as the content in those drives is changed not so often. That way I wouldn't have to re-query the info every time when navigating to the folder containing the links which would prevent the attached drives from waking up on said navigation.