I found a serious bug in multiple Omniverse Installers that can be fixed easily [WINDOWS]

TL;DR:
Multiple installers including Houdini, Maya, ConnectorCommon connectors and Blender USD branch use %USERPROFILE%\Documents in their batch install scripts which leads to nowhere on some machines preventing installation and creating inaccessible folders.

I humbly suggest making a registry query on start

for /f "tokens=3*" %%p in ('REG QUERY "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" /v Personal') do (
    set DocumentsFolder=%%p
)

and using %DocumentsFolder% instead.

Personal story or why this matters:
I have a pretty common setup with Documents folder moved to another(huge) hard drive so apps won’t clog system SSD. This was done by standard Windows means by choosing the location in the folder settings window.

Houdini connector wasn’t installing for me, I checked everything - Houdini installation, Omniverse settings, system variables, rebooted several times, nothing helped, it kept saying that some batch script is failing.

So I snatched the connector folder after it was downloaded, but not auto-deleted (3 seconds to do that, probably I’m doing debugging wrong and it possible to obtain these things for manual install, right?), ran the script and it failed on checking Houdini folder existence. Weird, considering other connectors and apps installed without a problem.
Except they haven’t.

I hardcoded the correct path to my Documents folder and ran the script manually, it installed correctly but Omniverse Exchange didn’t recognize it, so I decided to investigate. I found that %USERPROFILE%\Documents\houdini%%H doesn’t exist but %USERPROFILE%\Documents somehow does. And then a found a fake Documents folder.

So in my case real Documents folder is D:\Libraries\Documents\ but “User” folder obviously remains on the system drive C:\Users\username. Previously installed Omniverse app used %USERPROFILE% in the install script, haven’t checked that %USERPROFILE%\Documents exists, created it, resulting a new C:\Users\username\Documents folder, and put it’s stuff in there. And then another one. And another. So I indeed found multiple Omniverse connectors data in the fake Documents folder.

I moved everything to a real one, made a symlink with "mklink /J C:\Users\username\Documents D:\Libraries\Documents " and voila, Omniverse Exchange installed the Houdini connector correctly and my system is Omniverse-proof now.

However, it’s a crutch and I’m absolutely sure there will be more people with custom setups that will fall into this trap, after all Omniverse is aimed to run on complex workstations with non-standard folder structures. Also “installed correctly” plugins aren’t actually installed and most likely will cause errors when some other program will try to get their data from the real Documents folder.

I tested the registry query script shamelessly copy-pasted from StackOverflow, and it works just fine.

I hope this will reach all concerned plug-in developers (I’m pretty sure all others use a similar install process), and by this or another mean plugins will be updated to use registry keys instead of system variables.

Hello @sofiegrozovski! Appreciate your input on this matter. I created a ticket for this issue and sent it over to the dev team!

A dev ticket was created from this post. OM-63088: I found a serious bug in multiple Omniverse Installers that can be fixed easily [WINDOWS]