Bugreporter

Hi walt.farrell Your tip is good for self owned and administered computers and I would also suggest /J before /D in this case because junctions are better than directorysymlinks - they are served from the filesystem below, not the api above. It's also good to be warned that there are INDEED data-intensive subfolders that should not be synced during roaming so we need a distinction. Using junctions or dirsymlinks within roaming profile trees has its own speciality. I already have a special logonscript that can trigger an immediate task running as system that looks up the triggering user and the loaded profile, looks for a specific software and creates directory symlinks for specific folders that point to targets in the homedrive. But this construct is not as stable as needed, can have timing issues and I'm happy there was no more use for it - I really don't want to dig that up anymore. The way to go really is a tiny pointer system. I was informed that it is discussed internally, Thanks for that!!!

Hi Leigh, thanks for looking into this! I perfectly understand that this is a requirement that does not exist within APPX and MSIX, but these formats would be nightmares in my environments. I am very happy with the MSI approach and will definitely contact corpsupport to propose an optional system-wide pointer and optional overriding user-specific pointer that can handle variables or known-folder directives.

Hi Komatös, thanks for your opinion and greetings to Hamburg, I live there, too Unfortunately you are wrong, I wish you were right. %LOCALAPPDATA% is the designated personal space for userdata that may be left with the computer and discarded in case of roaming. %APPDATA% and "Documents" is the designated personal space for userdata that would sync to the server when roaming from computer to computer. %ALLUSERSPROFILE% goes to %Systemdrive%:\ProgramData and is a grey area where vendors may decide how multiple users share local data. %USERPROFILE% is the last resort, very unfortunately used by disorientated multiplatform ports, often coming from linux and I have seen quite some runtimes that lure developers into that error, (QT and what not), resulting in the same problem... The proper way of finding the correct locations is not by using these variables, but using the API and the "Known Folders" as described here: https://learn.microsoft.com/en-us/windows/win32/shell/known-folders (The Registry location for the personal pointers is here, btw: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders )

Hi Serif, during profiling the new V2 products and preparing a rollout, I noticed that you create an fill a user folder "%USERPROFILE%\.affinity" instead of using the common and designated locations %LOCALAPPDATA%\Affinity, %APPDATA%\Affinity or Documents\Affinity. It seems that somebody has forgotten to properly assign userpaths when porting code between MacOS and Windows? Going directly into %USERPROFILE% with software data causes problems with our roaming profiles on multiuser workstations. Is there a config file or regkey that I can use to point to a different folder? Or can I exclude the folder from syncing to the servers without losing valuable data for a roaming user? (Anyways, I have to say your MSI implementation and the software looks nice, I had no hassle preparing it and overlaying it with MSTs for startmenu restructuring, all-in-all a good job! I'm looking forward to push it to the clients in the near future...)