AIO move of User Directory from %AppData% to %LocalAppData%

Can you find where the installer chooses paths for the Gramps User Directory content? (Those Directories are not created until the first time Gramps is run.)

The Enchant, and gramps folders have changed in this version to use the &localappdata& folder:
whereas previous AIOs installed to the &appdata% folder:

And there was an anomalous empty folder added by the AIO to the other location named

From what I’ve found, the local folder is only supposed to be used for material that cannot be relocated. Gramps can (and should) use the roaming

The GTK directory appears in
    C:\user\ <username> \appdata\ local\

At the very end of install, after you choose to run (or NOT run) the Gramps application.

Check this out: What Are the Different Windows “AppData” Folders for, Anyway? - Bing video
[3:37 introduction of Local, LocalLow, Roaming]

From the freshly minted gramps.ini on a virgin PC:

Of particular interest is:

  1. the [geography] putting a \gramps\maps folder in the Microsoft browser caching control.
  2. the odd defaults in [paths] putting so much in the %userprofile% ( C:\\Users\\User ) path instead of the gramps subfolder of the Gramps User Directory


The whole gramps.ini

;; Gramps key file
;; Automatically created at 2023/09/10 20:55:19

;;addons-projects=[['Gramps', '', True]]

;;border-family=['#cccccc', '#252525']
;;border-family-divorced=['#ff7373', '#720b0b']
;;border-female-alive=['#861f69', '#261111']
;;border-female-dead=['#000000', '#000000']
;;border-male-alive=['#1f4986', '#171d26']
;;border-male-dead=['#000000', '#000000']
;;border-other-alive=['#2a5f16', '#26a269']
;;border-other-dead=['#000000', '#000000']
;;border-unknown-alive=['#8e5801', '#8e5801']
;;border-unknown-dead=['#000000', '#000000']
;;family=['#eeeeee', '#454545']
;;family-civil-union=['#eeeeee', '#454545']
;;family-divorced=['#ffdede', '#5c3636']
;;family-married=['#eeeeee', '#454545']
;;family-unknown=['#eeeeee', '#454545']
;;family-unmarried=['#eeeeee', '#454545']
;;female-alive=['#feccf0', '#62242D']
;;female-dead=['#feccf0', '#3a292b']
;;home-person=['#bbe68a', '#304918']
;;male-alive=['#b8cee6', '#1f344a']
;;male-dead=['#b8cee6', '#2d3039']
;;other-alive=['#94ef9e', '#285b27']
;;other-dead=['#94ef9e', '#062304']
;;unknown-alive=['#f3dbb6', '#75507B']
;;unknown-dead=['#f3dbb6', '#35103b']



;;proxy-order=[['privacy', 0], ['living', 0], ['person', 0], ['note', 0], ['reference', 0]]


;;view-categories=['Dashboard', 'People', 'Relationships', 'Families', 'Ancestry', 'Events', 'Places', 'Geography', 'Sources', 'Citations', 'Repositories', 'Media', 'Notes']



last-views=['dashboardview', 'personview', 'relview', 'familyview', 'pedigreeview', 'eventview', 'placetreeview', 'geo1', 'sourceview', 'citationlistview', 'repoview', 'mediaview', 'noteview']
;;no-given-text='[Missing Given Name]'
;;no-record-text='[Missing Record]'
;;no-surname-text='[Missing Surname]'
;;private-record-text='[Private Record]'
;;tag-on-import-format='Imported %Y/%m/%d %H:%M:%S'


children=[22.605613425925927, 9.132667824074074]
citationlistview=[18.084490740740744, 6.781684027777779, 9.042245370370372]
citations=[31.6478587962963, 13.563368055555557, 14.286747685185187, 18.084490740740744]
dbman=[22.605613425925927, 7.595486111111112, 14.105902777777779]
events=[9.042245370370372, 13.563368055555557, 9.042245370370372, 9.042245370370372, 36.16898148148149, 18.084490740740744]
eventview=[9.042245370370372, 20.797164351851855, 13.563368055555557, 18.084490740740744, 9.042245370370372]
familyview=[6.781684027777779, 18.084490740740744, 18.084490740740744, 9.042245370370372]
mediaview=[18.084490740740744, 6.781684027777779, 9.042245370370372, 18.084490740740744]
noteview=[31.6478587962963, 6.781684027777779]
persontreeview=[22.605613425925927, 6.781684027777779, 6.781684027777779, 9.042245370370372]
placetreeview=[22.605613425925927, 6.781684027777779, 9.042245370370372]
repoview=[18.084490740740744, 6.781684027777779, 9.042245370370372, 22.605613425925927]
sourceview=[18.084490740740744, 6.781684027777779, 13.563368055555557]



We now support the XDG Base Directory Specification. See pull request #1368.

These directories are defined in the file. The default locations can be customised either by using the environment variable GRAMPSHOME or individually by using XDG_DATA_HOME, XDG_CONFIG_HOME and XDG_CACHE_HOME.

In addition to this Gramps can also detect the directory structure used by previous versions.

In comment reply to that PR, GuLogic cites references to GLib Funtions (but unfortunately does not link to the original) about Local vs. Roaming… then asks if that seems reasonable.

I am strongly suggesting that that is NOT reasonable for 2 reasons:

  1. less important: consistency with previous releases
  2. critically important: it is incompatible with Gramps configurations following users using local network logins on different workstations. (This creates issues for using Gramps as an education tool or at Historical/Genealogical Societies. Those issues would not exist in previous versions. So this is a downgrade in capabilities.)

Here are the links to the documentation:

1 Like

It is arguable that leveraging the %localappdata% for a more resource-friendly and smarter backup strategy. That could be a good enhancement.

A large number of generations of backups (whether due to backup on exit or automatic backup intervals) in the %userprofile%/AppData/Roaming folder creates a HUGE burden when roaming. (Logging into a different workstation syncs the Roaming profile from the File Server. The Local profile is not sync’d.) So, the current backup in the Roaming and the archival backups in Local would ease that burden.

This deserves some exploring. We need to understand their logic/justification for selecting the Local over the (more broadly compatible) Roaming. It might not suit our user’s model in small home networks.

It was new for Win10 too. So that doesn’t have a lot of validation time behind it.

The python platformdirs module may be worth investigating. It is available as a MSYS2 package.

By default it returns the Local path for the user data and user config directories, but the parameter roaming=True can be supplied if the roaming versions are preferred. Alternatively, we could just modify the output of the GLib functions on Windows.

1 Like

That seems easier for now.

Can we stay with what is done in 5.1 for now? And then change (if necessary, after investigating) in 5.3 … rather than changing twice.

(Just did a fresh install of 5.1.6 to double-check that it still did used Roaming, not Local. It does.)

For me the main justification is that roaming is risky, because it can create inconsistencies between different copies of your database, which now sits in roaming too. It’s a small risk, because the average user is not on a corporate network, but if he is, roaming means trouble.

I also did a quick check on my PC, with a new Windows 8.1 config, running in VirtualBox. And there is a roaming folder in that too, so it’s not new for W10.

It is not “Roaming” that is new in Win10, it is “local” that is a new default for GLIB under Windows 10.

And while Roaming may be risky, supporting it is the current behavior. So eliminating it should be a thoughtful process. Since Roaming profiles support at the OS level requires a file server or network server, and deployment requires enabling a option, it is arguable that the administrator will be aware of the risks.

From MS leaning Center:
In Active Directory Administration Center, navigate to the Users container (or OU) in the appropriate domain. Select all users to which you want to assign a roaming user profile, right-click the users and then select Properties. To specify a mandatory roaming user profile, specify the path to the NTuser.

Ok, check. I didn’t understand that you were talking about the default. My fault. :slight_smile:

The problem is though, that in an environment with an administrator, he or she may not be aware of the risks that roaming inflicts on the user, unless he or she is aware of what Gramps does. These risks are much smaller for bookmarks and settings saved in roaming, but Gramps has the whole database there, and maybe even more than one.

In reality, I bet that more than 99 % of Gramps Windows users are not on a domain, so it will only affect Gramps installations in a school, or a library, like the one in our Dutch Genealogical Society. And that 1 % may cause us a lot of pain if they start complaining about database problems.

OTOH, since every Gramps in the wild stores all data in roaming, it is quite likely that no user is actually in such a domain, so IMO, this is a red herring.

Another thing is, that this whole XDG thing is Linux based, so there is not much rationale to enforce it on Windows users, other than where it helps us to make the software act more consistent, and easier to maintain.

Actually, the roaming folder are not for DATA, it is for important software settings and configuration files that shall follow a user’s user profile…

Any Domain Administrator knows about and can take care of data that is in those folders, regardless of if they have roaming user profiles or not.

Databases and other user data should in a perfect world be placed in a sub-folder under the Documents folder or in a user configurable folder…
Sadly, a lot of companies, including Microsoft ignore this…

When I worked as a domain administrator, one of the biggest problems was software that stored user data and databases with user data under the appdata/roaming folder, because some of those databases could be extremely large and should be stored on other storage servers than where the user profiles were stored…

This is also regarding backup of user profiles etc. in a domain administrator’s perspective.

I should also add, No data that a user should or must alter shall be stored in neither “Local” nor “Roaming” or any other folder under “appdata” unless it is configuration or settings that can be altered/configured in the software, just as same type of app settings/configurations should net be stored in Registry if a user is expected to change them in any manner other than configuration settings in the app/software itself.

Please cite where this guideline can be found.

It does seem reasonable that the Database, backups and Media should be in the Documents. (Particularly since that directory is simple to configure to sync to a fileserver.) But Microsoft has multiple strategies for sync… including SharePoint, Sync Center and OneDrive. It is beyond the scope of 5.2 to introduce new ways of complying. So we shouldn’t have a major filepath change in 5.2 only to change again for the 5.3 verison.

Still having references for guidelines tends to shorten discussions about development for 5.3.

You are mixing different services together; domains and user profiles have nothing to do with other sync services (edited: not completely true)…
When you click on a domain network folder or file and choose to sync it, you actually use the built-in sync in Windows, e.g., Sync Center.
Same if you have Workgroups or network shares on a NAS or similar devices (Shared Folders).

but still:
The APPDATA folder (ALL SUB FOLDERS) are for Application specific data, e.g., settings in ini files or json or any other type of a file that can contain configurations and settings… or app-caches.
If the application has a sync service, e.g., firefox, edge etc. that can sync your settings to other computers via an internet service, they should use “Roaming” to store that data.

If you want to sync your user data or database, that should be stored in “Documents” or a user specific folder either on the C: drive or any other storage device connected to the computer.

The information is in all of the books Microsoft have published for their courses to become a Microsoft Certified Technician/Domain Administrator etc.

This is Windows Administrator and Windows Development specific… The 6-8 books I read back in the day to become a MCSE/MCSA was each between 650 and 800+ pages…

Sharepoint is an Office Service, and if you work against a Sharepoint server, you usually save your documents directly to the server from within your Office Software, you should not sync system data to Sharepoint other than SP specific data.

Sync Center is a service for network use, e.g. workgroup, domain, shared folders etc. and is also just a service to sync user data. You can of course sync system folders/data with it, but that is something you set up manually when you have a network share you can access from your local computer…
As far as I remember Sync Center is not supposed to be used to sync files to a cloud service.

Onedrive is a document storage in the cloud, and by that, it should mostly contain user data, to sync the “Roaming” folder and other system folders to One Drive is a “super user” operation, it is not something a “normal” user should need to do…

If you choose to sync system data like the Appdata folder, that is again something a “normal” user should not need to do… as long as they have some kind of backup (e.g., Windows backup) configured.

It is a reason for why those folders are hidden as standard.

oooh… and just remember that sync. is NOT the same as backup (info for those read this and is not sure and think OneDrive or google drive or Dropbox is a backup solution…).

I am not mixing them. I am listing a few alternatives. Perhaps you are assuming that I am suggesting using them in concert. I did not and am not.

However, I am suggesting that there are multiple approaches offered by Microsoft and people will pick and choose (often blindly) from those or other systems… or they may use no system whatsoever. Not even the built-in backup on exit or timed backups. Or they might try to use the tools incorrectly or to use incompatible pieces in disharmonious concert.

mix/list… same same…

My point is that most of those services does not use the AppData hidden folder structure for storage, those services are for syncing documents and other user data… if someone find out that they want to sync the “Roaming” folder in addition, that is a choice they make…

Just to be clear… if Gramps doesn’t have an in-software sync function to an online server service that provide services to sync the Gramps settings/plugins between computers, the app data for Gramps should be stored in “Local”, but in practice, on a standalone computer, not connected to a local network, the “Local” folder and the “Roaming” folder “behave the same way”, both are only stored on the local computer.
If you have a software that provide an in-software service to sync your settings between different computers, the applications configuration files, settings etc. should be stored in “Roaming”.

If you as a person want to set up a sync/backup of your Gramps Settings that will be a manual job, and it doesn’t matter if a folder is under “appdata” or on your D-drive… you choose the folder manually anyway… it has nothing to do with the “Roaming” vs. “Local” folders…

As I wrote, or hope I wrote, you can find more about this in the course material for Domain Administrators and Microsoft Certified System Engineer paths… (I know it is called something else today, but its late). There is also a lot of articles explaining the differences and usage/best practice online…