I often wish that I knew more about a backup file found among old sets of DVDs. I don’t want to create a destination, import a backup, and blunder through the Data just to identify the contents.
It would be helpful if a Note in a Tree could be designated as the source of exported content to a ReadMe.txt file. This file could be inserted at the top-level of the backups generated by Gramps.
If I’m about to do something foolishly risky in Gramps, I’ll often make a special backup as a recovery point. But the difference between this backup & the next can rarely be explained in the filename. A description metadata would probably work… but I always walk away during the backup and neglect that final bit of housekeeping. So popping up the Note Editor in a bottombar with that designated note during the backup options would be a nice nag.
Perhaps a Database summary report (plus the System Info from the Bug Reporting Assistant) & could be embedded too… or maybe a Book could be generated for a more expansive look at the focal data… like, a person who does better with visual learning might want to have a graphical Pedigree or Fan Chart report on the Home Person instead of a text report.
If the backup restore had a (suppressible) display of the Database Summary during the file selection in the Restore process, there’d be less guesswork during selection. And if the ReadMe was displayed as the Restore was in progress, you could use it as a Distribution Note system. Tell people the points of interest (or recent discoveries) in a Tree distributed in backup format.
Right now, I can add such annotations to the archive as a post-processing step. Just generate the content & add it with 7zip.
What does Gramps do when you (attempt to) import this file?
The Gramps import entirely ignores the ReadMe.txt and the PDF report I’ve added.
1 Like
It’s actually strange that XML in General, but also the and the packed Gramps archive doesn’t have Metadata fields where information for the file could be written…
Personally, I always add a date in ISO format and a descriptive name for any backup file, regardless of software. In addition I usually try to add them to a folder structure that also are descriptive…
Actually you can add a comment in the xml file, and just open the file with a text editor like VS Code, Atom etc.
But, Yeh, I agree, it would have been nice if there was a “Note” or Description Field that somehow was easy to read without importing the data or open the file itself in a text editor…
Make a feature request
1 Like
Hadn’t considered the metadata option for XML. Good point! (I was thinking of OS level metadata.) Might be a nice supplement for knowledgeable users. Nontechnical users like something that’s less covert.
I consider ideas posted here to still be in the brainstorming phase.
Threads here get input. Feature Requests tend to be taken literally and are seen as more immutable.
My workflow is often a bit too convoluted. So I appreciate people shooting holes in my ideas. And I also transcribe ideas users posted in other forums.
There are 2 general styles of feature requests that appeal to different Developer personalities.
Some Developers like an objective without pushy specifications… they’d rather come up with their own approach. Other developers prefer a fully fleshed out feature specification … they even like mockups of a GUI.
But I rarely find any developers who enjoy prying out input through long discussion threads. Teasing out ideas is painful.
I had created Feature Request 11817 (Backup option: Add Note selection for ReadMe.txt insertion) but realized that it was underdeveloped. So the developer is being tortured too much with the discussion.
I’m not a developer, so you’re not torturing me 
, I’m only volunteering/helping out with triaging and checked and found your feature request, and find it very interesting 
Although the bugtracker has developer beside my name I believe that is only a permission level so I can triage.
3 Likes
OK, I’ll just torture you with questions about the iconset template in the wiki then! 
That port from mediawiki seems to be your baby. It is great but confuses the heck out of me. (I haven’t made the leap to understanding the template design & parameter passing conventions yet. My confusion is what lead me to add internal usage documentation to a few wiki templates. I document as a method to learn the pattern of how they were coded. But I’ve only gotten to a few of the ‘include’ style template so far.)
1 Like
As a developer, and as a user, I’d suggest that on every backup, Gramps invites a user to enter details of what the backup contains.
Further - It would ‘automatically’ add an entry, perhaps to a database file created for the purpose named something like ‘backup history’ to state the date and time of the backup, plus any additional information. The restore can then also reference the fixed identity file and display the ‘latest’ item which is the current content of the backup, and enquire if this is the correct one (or, under a setting, not do so)
So the use case would be something like
Decide to do a backup
Yes - start process. At commencement the system asks ‘Do you wish to add some notes about this backup in addition to date and time?’
options - no - use standard date and time only
yes - add a description or ‘use previous’
write the preferred option and backup files
at end, write another record to the file to state that backup (date, time) ended normally.
On restore
invite user to review backup history log to check that this is the backup they expect. Invite agreement
run backup, or abort.
just my first thoughts
Richard
6 Likes
I’m ambivalent about the use case described. While many of the stages make sense, the thought of transiting a series of dialogs to do a process is not good. (At the very least, it would have to be like the Export Assistant… which informs the users how many hoops have to be leapt through & which hoop they are leaping.)
In some instances, a manual backup is prompted by the system beginning to show symptoms of being fragile… such as interface latencies. So you may want to plug in a thumbdrive and do a quick backup in case the box smokes. (Or the monitor failed and you’re having to do a headless backup.) Each additional step adds anxiety to the process.
Perhaps the features could be added without steps that require adding recursive dialogs?
And a ‘backup successful’ write to file should be considered thoroughly. Does this dirty the file? If so, it would cause an unnecessary backup upon exit. Naturally, there shouldn’t be a success dialog that has to be dismissed. Those modal dialogs interfere with OSes waiting for apps to complete before shutdown.
Perhaps it should be a quiet success verification? Maybe just writing it to the Session Log?
Speaking of the Session Log, maybe copying that to the non-tree (informational) part of the backup could be an option. If the automated backup was set to ‘upon exit’, the Session Log would provide a sense of what differences could be expected.
I think the idea of a confirmation “Backup Successful” would be useful (for example, I use Macrium Reflect for Windows backup and this gives a “Backup Completed Succesfully in 25 mins” or similar etc) for a manual backup. When doing a manual gramps backup, all ones sees the small progress bar bottom left and it’s silent on completion (I note emyoulation’s point about a silent completion on automatic backup)
I’d rate a “Backup Successful” for manual backup notifcation more highly than writing comments/backup log, but they’re both good ideas. Perhaps the log could include: n records written, x people, y events p citations, q notes etc from database kkk on YYYYMMDD HHMMSS
1 Like
My earlier post was something of a brain dump, and I’d concur about the devil’s in the detail.
Some things about backups i hold dear at the level of being ‘laws of physics’
- All information needed is collected at the start
- the backup will document itself, and if possible, permit restarts from waypoints in the event of failure
- the user will always be able to determine whether the backup they started was completed normally.
- the user will always be able to determine the content - automatically added by date and time and identifier, plus other information they may wish to add.
Nice to have are the tools to check all this - configure things like identities to added or incremented automatically / use same as last time / blah blah / log record counts, sizes, time taken, transaction counts or whatever. Number of copies to make (off-site additional copy…)
Someone mentioned record counts, and having a profile available in a log is hugely useful - the day you need it.
Richard
1 Like
What about adding the output of a selected ‘Book’ of reports to the backup archive instead just a Note?
Adding a couple new reports could round out the feature:
- a report that prints a particular Note (similar to the ToDo Note addon report except that it wouldnt have the extra noise of headers, indents, ID. This would let the user layout a preformatted Note.)
- a QuickView shell report (similar to the QuickView gramplet, this Report would allow any QuickView… for a particular single record… to be output)
A book could evolve outside the development cycle and would be a lot more flexible than hard-coding a narrow-scope feature.
There is a pull request #1403 that adds a tree tag to the Gramps XML in which metadata such as a description, contributors, copyright statement etc… can be stored.
I need to review it again, but it should be merged shortly.
That PR1403 takes the Metadata approach by embedding the data in the XML of the Tree.
However, it does NOT address the primary goal of being able to quickly identify what a .gpkg contains. With metadata in the XML, that would require decompressing (twice: a GZIP compressed .gramps inside a compressed .gpkg) the file and then hand-parsing the XML to determine what program reads XML file, which version, which Tree, etc. (Although the following is a seemingly unrelated complication, note that currently a mismatch of OSes and network destinations for Media objects can also make restores of a Gramps backup .gpkg problematic. This creates a difficult to troubleshoot failure. You don’t know whether to attack it as a XML version conflict with the tree or the paths of the media collection.)
A ReadMe.txt could also be displayed as Gramps restores the archive. The Database Summary would set the user’s expectations about how long the process could take: a 1,000 person tree restore versus a 5,000,000 person restore have totally different expecations… seconds versus hours of processing. Reading the ReadMe.txt file during a restore process could also be a productive utilization of the user’s time.
If a repeatably generatable Book of Report could be targeted for inclusion at the top level of a .gpkg archive, then a Plain Text README.txt (or About.txt inclusion) that has the Databaase Summary Report (which was being harmonized with the Import summary report. see 11881: [Database Summary Report] Include counts of all item types. and PR1097. There’s another enhancement request to make ALL imports give a final import summary report. As an example, GEDCOM import gives no summary, just a list of failures.)
Cornell has a pretty decent section listing objectives of a ReadMe.txt file covering concerns in making legacy archives remain usable as technology changes.
1 Like
Note that the GEDZIP (.gdz) for GEDCOM7 docs specifically recommends against including a similar approach with MANIFEST.MF or any URL beginning META-INF
The FamilySearch GEDZIP file format in the FamilySearch GEDCOM Specification, version 7.0.12; page 103 of 111
Many other zip-based file formats (such as jar, epub, docx, GEDCOM-X) assign special
meaning to the zip directory META-INF and the zip file names MANIFEST.MF and
META-INF/MANIFEST.MF . These have no special meaning in GEDZIP and it is recom‐
mended that they not be used in a GEDZIP file, both to avoid confusing systems that look
inside zip archives to determine their file type, and to leave open the possibility of their
addition in a future version of this specification.
Here’s a possible sample:
<Intro Note text>
Family Tree name: Example
XML file: Example-2023-05-24-17-24-17.gramps
Format MIME type: .gramps (XML format Gramps XML - Gramps)
Schema version: 18.0.0
Compression: GZIP
Path /home/districtsupport/.gramps/grampsdb/63e1550c
last accessed 05/24/2023 05:22:13 PM
Researcher:
Address:
Phone:
Email:
Database owner:
Address:
Phone:
Email:
Genealogical research focused on:
GARNER VON ZIELIŃSKI, Lewis Anderson (Big Louie)
born: 21 June 1855 in Great Falls, MT, USA, son of GARNER, Robert W. (Robert) and ZIELIŃSKI, Phoebe Emily (Phoebe).
married MARTEL, Luella Jacques (Luella) on 1 April 1875 in Paragould, Greene, AR, USA.
died: 28 June 1911 in Twin Falls, Twin Falls, ID, USA at the age of 56 years, 7 days.
buried: 1 July 1911 in Twin Falls, Twin Falls, ID, USA.
Direct ancestors: 6
Direct descendants: 72
Statistics:
[This order is not logical but matches the Import Statistics report. Maybe it matches the order of sections in the file itself?]
Number of People: 2157
Number of Families: 762
Number of Sources: 4
Number of Events: 3432
Number of Media Objects: 7
Number of Places: 1294
Number of Repositories: 3
Number of Notes: 19
Number of Tags: 2
Number of Citations: 2854
[Maybe could add a statistics line]
Number of Custom Attributes: ?
Gramps: 5.1.5 (a personal genealogy program)
LANG: en_US.UTF-8
OS: Linux
Distribution: 6.2.15-200.fc37.x86
There’s already a built-in feature of Gramps that specifies an introduction note: the Narrated Web Site report.
Perhaps it is time to codify how these features interact with the Tree and data can be leveraged for re-use across multiple features.
If a Researcher and an Owner persons end up replacing the extraneous
I’ve belatedly realized that the date that the backup is made is not terribly helpful.
It is more significant to know the latest modification date of any record in that Tree. And for document version control purposes, an option to reset the Last Accessed date shown in the Family Tree Manager to the Last Modified date of that last changed record would be useful.
If the backup is used in the distant future, schema number of the XML in the title of the backup would be helpful.
