Why is there a %USERPROFILE%\.affinity folder in Windows?

[Bugreporter]

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...)

Edited February 13, 2023 by Bugreporter
typos2

[Komatös]

Hi @Bugreporter and welcome.

Version 2 is designed so that when several people use the same PC/laptop, each has their own settings files. And the decision not to create this directory in one of the subdirectories of APPDATA certainly has to do with easier administrability.

[Bugreporter]

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 )

Edited February 14, 2023 by Bugreporter
add, typos

[Leigh]

V1 used %APPDATA% but V2 now uses %USERPROFILE%. Our V2 Windows apps were designed to be sandboxed, hence the MSIX for installation. If you're having issues installing/deploying our apps on a network, please send an email to corpsupport@serif.com and we can help you further.

[Bugreporter]

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.

 

 

[TiRohn]

Hi there

I might have a similar question, although I think not connected to the issues mentioned by @Bugreporter.

@Leigh: is there a way to move the User Data folder to another location (like on a second drive), reason is simple: I'm running out of disk space on my C-Drive.

Thanks and regards
TiRohn

[Leigh]

2 hours ago, TiRohn said:

Hi there

I might have a similar question, although I think not connected to the issues mentioned by @Bugreporter.

@Leigh: is there a way to move the User Data folder to another location (like on a second drive), reason is simple: I'm running out of disk space on my C-Drive.

Thanks and regards
TiRohn

Not "officially" within the app. However, someone did something similar in V1 here but it's not something we would recommend as it cause unforeseen issues with the app(s).

[walt.farrell]

2 hours ago, Leigh said:

Not "officially" within the app. However, someone did something similar in V1 here but it's not something we would recommend as it cause unforeseen issues with the app(s).

I run with my .affinity folder on a separate drive on my desktop machine, and it doesn't seem to cause any problems. (I also ran with the V1 AppData (just for Affinity) moved, without apparent problems.)

Specifically for the .affinity file it is a bit simpler than described in the post you linked to, though the operations are basically the same. Here's approximately what I did:

1. Create E:\Affinity-Data
2. Ensure no Affinity V2 applications are running.
3. Copy the contents of C:\Users\Walt\.affinity to E:\Affinity-Data
4. Delete C:\Users\Walt\.affinity
5. Start a Windows Command Prompt by right-clickng on its icon and choosing More > Run as Administrator then issue the following commands
6. cd \Users\Walt\
7. mklink /J .affinity E:\Affinity-Data

 

[Bugreporter]

2 hours ago, walt.farrell said:

I run with my .affinity folder on a separate drive on my desktop machine, and it doesn't seem to cause any problems. (I also ran with the V1 AppData (just for Affinity) moved, without apparent problems.)
Specifically for the .affinity file it is a bit simpler than described in the post you linked to, though the operations are basically the same. Here's approximately what I did:

1. Create E:\Affinity-Data
2. Ensure no Affinity V2 applications are running.
3. Copy the contents of C:\Users\Walt\.affinity to E:\Affinity-Data
4. Delete C:\Users\Walt\.affinity
5. Start a Windows Command Prompt by right-clickng on its icon and choosing More > Run as Administrator then issue the following commands
6. cd \Users\Walt\
7. mklink /J .affinity E:\Affinity-Data

 

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!!!
 

[walt.farrell]

@Bugreporter: That was specifically in response to Leigh's comment to @TiRohn, whose situation is different from yours.

Thanks for the hint about /J.

[TiRohn]

Hi @Leigh and @walt.farrell

Thanks so kuch for your tips, I will take a chance and try this on my system (don’t know yet when I will find the time to do this though).

Kind regards

TiRohn