Recursive autobackup .gramps filenames


In gramps, there is no File -> Save function. Instead, the program uses “autobackups” after a certain time interval and/or on exit. On my system, the latter option yields .gramps file names like myname-YYYY1-MM1-DD1-HH1-MM1-SS1-YYYY2-MM2-DD2-HH2-MM2-SS2-...-YYYYn-MMn-DDn-HHn-MMn-SSn.gramps after the n-th restart and exit of gramps. This is very annoying. Is there any solution to just have this default File -> Save function where I can specify a file name to save the data?

Thanks a lot for any help,

ps: I would find it much easier if you would enable issues at github.

gramps --version
Gramps Settings:

python : 3.9.2
gramps : 5.1.3
gtk++ : 3.24.28
pygobject : 3.40.1
pango : 1.48.4
cairo : 1.17.4
pycairo : 1.20.0
osmgpsmap : 1.0
GExiv2 : 0.10
ICU : 68.2
PyICU : 2.6
o.s. : linux
kernel : 5.11.11-arch1-1

Use “Export” if you want to save to a specific file with a specific name.
That is the closest you get to “Save as…” Because you are working in a database… so only way to get data out is to export from the database and transcribe it into another format. This is also what the backup do, it creates an exported dump of the database in a XML format, while the database it self can be any supported type, default in 5.1 is sqlite as database backend (its not a human readable file format)

Those are the automated backups. If you want to make a manual backup, use Family Trees → Make Backup… where you can override the default filename & preferences backup path.

Note that Gramps commits transactions continuously in the selected database backend. So there is no ‘Save’. A work session has an Undo history to reverse transactions.

The backup is in our custom XML data interchange format … which is not used for live data - only for archival and data transfer purposes.

Additionally, support for Gramps is community-based, not done by our few overtaxed Developers. (Although they sometimes put us back on track if the community goes haring off in the wrong direction. But the community tries to free up their time for development & bug fixes.) So GitHub is not a support channel. The official support method is via the Gramps-User maillist and this forum is a support experiment started about a year ago.

With pickled BLOBs! So using database tools to do mass manipulations is problematic.

(There is a current initiative to convert objects from pickled BLOBs to JSON. But this isn’t commercial software development where there’s a fixed schedule. Don’t count on anything that hasn’t already been released.)

You can turn the backup on exit off in Preferences. This functionality was added because all too often, when a user had a problem, the answer was “No.” when asked if they had a backup.

For myself, I thought adding the minutes and seconds was a bit much on the backup on exit (I do not use the incremental backup while Gramps is open, I have a large database) so I modified the code leaving the date and hour. I modified file \gramps\gui\ at line 1208

timestamp = '{0:%Y-%m-%d-%H-%M-%S}'.format(
timestamp = '{0:%Y-%m-%d-%H}'.format(

This is the same backup file name I have been using from the start.

1 Like

Thanks a lot for your answers.

When I Make Backup and open the obtained .gpkg file, a message appears that I should consider taking a simpler relative media path. Also, I should move the media files to the new position. When I close gramps and re-open the .gpgk file, a message occurs saying that the media directory already exists and that I need to delete it. In this path, copies of the media files were created.

Is there a way to simply export/import the database without running into this media path issue and without moving the media data and without having those copies?

I am confused with the different database formats. @StoltHD writes that the default (i.e. of the autobackup .gramps-files?) is sqlite. In my case, this default autobackup .gramps file is 11 KiB in size. If I export the family tree as SQLite, however, the result is 368 KiB in size, so this is not the same? I dont understand @emyoulation’s comment about pickled blobs.

The comment from @DaveSch does not solve the issue, its a workaround to rename the files. I dont want to follow this way, as my gramps version then would differ from the supported one and potentially corrupts who-knows-what other function.

I think you wrote that comment to the wrong person, since I am one of those that really have tried to push for dropping the Blobs, and use mongodb just becaose of the, even though the driver is out of date…

I actually think Gramps could have benefitted greatly by using a Graph Database Backend, or at least a triplet store, Either that or actually using ALL the benefits of a relational database…

It’s a huge job to do those changes, so hopefully there will be a change when the Berkeley thing is left…

Maybe in version 10.65 or something…

The note wasn’t actually to you, merely leveraged & expanded upon your comment.

1 Like

Gramps natively edits and reports using a database (recently changed from BSDDB to SQLite) file. However, databases are highly dynamic and subject to easy corruption. And the current format uses an arcanely pre-digested (pickled) format for large chunks of data (BLOBs or Binary Large OBjects) that is not supported by most database tools.

The database files are buried in obscurely named folders in a ‘grampsdb’ folder found in the path defined by your Family Tree Database path: in the Family Tree tab of your preferences. DO NOT TRY TO MANAGE THESE MANUALLY! Gramps does that for you and the files are buried to keep inexperienced users from accidentally mangling them.

So we use an archival and data exchange format that is independent of the problems and version variations of database engines. It uses XML-format (with a ‘.gramps’ file extension) text files and are typically compressed into .gpkg archives that can ALSO archive media objects. The XML (compressed or not) is imported into Gramps to rebuild a fresh database file. (To confuse things a bit more, Gramps recently added support to let us try other database engine backends. The behavior of SQLite had benefits over the old BSDDB backend — so Gramps switched preferred database engines in 2020.)

@StoltHD correctly points out that Gramps allow lots of export formats. This is important to his workflow because he uses a wide variety of research applications. But our custom XML-based formats are the only formats that are LOSSLESS for exchanging Gramps data. Those appear in the Export options as “Gramps XML (family tree)” {which writes a .gramps file} or “Gramps XML Package (family tree and media)” {which writes a .gpkg file}.

Gramps does not care what the archive file is called nor where it is stored. That is strictly to make it easier for you to recognize which Tree is archived and how old the archive is. @DaveSch felt the timestamp detail in the filename made it harder to take in at a glance. So he simplified his auto-naming.

1 Like

I believe you really don’t need to even modify the Gramps code

You can also define the naming pattern for the backup filename by setting the paths.quick-backup-filename in the ~/.gramps/gramps51/gramps.ini key file

mentioned in Advanced backup filename setting section. Code that relates to this

1 Like

The automatic backup is hard coded as FileName-yyyy-mm-dd-hh-mm-ss It accesses gramps.ini for the backup location but not for the file name.

This makes sense when using the incremental backups while Gramps is open.

The Quick Backup allows for user naming options. And the gramps.ini file can be manually edited to offer the user a default option.

I have edited both so that both offer the same naming scheme.FileName-yyyy-mm-dd-hh

@DaveSch Thanks for the correction maybe a feature request to also make paths.quick-backup-filename or a similar key (eg: paths.automatic-backup-filename ) be the filename?