Reproducible bug in Zoho Workdrive sync agent for Windows
I've observed a recurring and reproducible failure in the Windows desktop app for WorkDrive, related to the registration of the OverlayIcon handlers that are added to the registry. When I installed Windows 11, I configured my
ProfilesDirectory (C:\Users, by default) to be located on a different storage volume (E:\Users, in my case), by way of the
System Preparation Tool (sysprep.exe) on the Windows installation media. The WorkDrive app installer detected this without issue and correctly placed its files in an appropriate directory under %APPDATA% (E:\Users\%USERNAME%\AppData\Roaming\…) and operates smoothly, however I noticed that the overlay icons meant to indicate sync state in the File Explorer never appeared. I used
Autoruns64.exe from the Microsoft
Sysinternals Suite to review the relevant registry keys and values for all of the overlay icons present on my system and the cause of their absence became instantly apparent.
Though the iconoverlay.dll files were located amongst everything else in the install directory, when the installer had constructed the values to add to the Windows Registry, it did not reference that location but rather what appears to be a hardcoded one applicable for the default ProfilesDirectory placement (C:\Users\%USERNAME%\AppData\Roaming\…) which kept them from being loaded as expected. While admittedly this is a minor inconvenience, I would still like to see it resolved, if possible. Without seeing the source code for the installer it's impossible to say for certain, but I believe a viable solution could be affected by simply enumerating the %APPDATA% user environment variable when constructing these registry values in the same manner as during the file copy process, or just more tightly coupling the verified destination of the app files to those registry entries so that they don't end up mismatched.
I'm happy to evaluate any test builds you might produce in an effort to correct the issue; I realize this is somewhat of an edge case, even if it isn't a "hack" but indeed a Microsoft-supported approach to keeping user data separated from system files so that they are more likely to survive the operating system being reset or wiped and rebuilt anew. I hope the fix is as minor as I'm positing, and thanks for making an otherwise great tool.