Could the Export functions for Gramps XML formats be streamlined?
Say that a .gramps file started only exporting as plain text XML. If compression is selected, writing XML would then force a change to the .gpkg format file extension? (Perhaps the .gpkg format should be the default?) Also, the Gramps XML files added inside a .gpkg archive also forcing to uncompressed .gramps XML files, then the inefficiencies of recursive ZIPping are minimized.
The current exported .gramps file format can be ZIPped or plain text. And the .gpkg format can include ZIPped versions or plain text .gramps files. I consistently run into .gpkg files that have 3 levels of compression, requiring recursive decompressing before allowing the XML to be inspected.
One of the recursive compression problems is: If a .gramps XML is ZIPped, there is an identically named uncompressed XML file (with the same file extension) within the .gramps file… creating an ambiguous file overwriting issue when decompressing the file for manual inspection of the XML. (You cannot just decompress the files into the same directory with the ZIP.)
For backward compatibility, the import side of Gramps could continue to support finding a ZIPped .gramps file and even those darned recursively ZIPped files inside a .gpkg archive. The change would only be in the preferred behavior on the exporting side. And the change would just cause the ambiguous cases in the wild to simply fade away.
The inclusion of .zip as a recognized extension would simplify life too. If Gramps also recognized it as a potential .gpkg renamed file and validated the contents in the same way, there should not be a need for any additional code. Attempting to import an invalid .gpkg file already fails, albeit in a less-than-graceful manner.
Our .gpkg files are rejected as uploads to our MediaWiki website, Discourse forum and as invalid eMail attachments in many eMail gateways. But a .zip attachment would be valid. If Gramps recognized the .zip extensions as possibly importable, there would be fewer steps involved in transferring sample tree data.
Although Gramps CAN import a .gpkg file into a new, blank Tree, my preference is to NOT do restore directly from a .gpkg archive. This is because those archives can include media. And media creates an extra level of complexity. (Media files are even more complex since I switch between using Gramps on Linux and Windows. The paths get really ugly.)
So my alternative is use a ZIP tool to extract the .gramps file from within the .gpkg archive into my Documents folder. Unfortunately, the Archive Manager that comes with Fedora gives errors when trying to extract. 7zip on Windows had no problems.
It may take several extractions to drill down to the uncompressed data.gramps file. The backup I did today with media extracted a .gpkg from the backfile, then a compressed data.gramps, then a plain text data.gramps file. Since: the .gpkg was the same name as its parent; and, the compressed and plain text were both data.gramps files; the junior namesake overwriting the parent file wasn’t an option. Had to jump through some destination folder creating hoops.)
Since the name is generic (data.gramps) in the .gpkg archive, I will rename that .gramps file to match the .gpkg Then creating a new, blank Tree; use “File → import” menu to restore that .gramps file to a Tree database.
This 10-year veteran user issue posted to the maillist is an example of what happens when trying to restore a full backup:
Medienverzeichnis /home/_________.gpkg.media existiert. Lösche es erst und wiederhole danach den Importvorgang
Media directory /home/ _________.gpkg.media exists. Delete it first and then repeat the import process
The only option is the “Schließen” (“Close”) button.
It also needs an alternative that does NOT require the absurd suggestion to blindly Delete media folder. It should allow import the Tree data without even attempting to import the media.
Multiple feature requests exist … going back a decade. There’s an opportunity to close the duplicates
- 0007156: 2013-10-23 .gpkg import won’t work if media directory already exists
- 0009232: 2016-02-04 Default base path for relative media paths is inappropriate.
- 0009234: 2016-02-05
Error extracting the stored data [Fehler beim Entpacken der gespeicherten Daten]
- 0009658: 2016-08-26 .gpkg import won’t work if media directory already exists
- 0009667: 2016-08-29 .gpkg import won’t work if media directory already exists (and long file path/names)
- 0010162: 2017-08-14
Guidance for Changing the base path for relative media…" is confusing
- 0011087: 2019-04-02
Error extracting into c:"location".gpkg.media
- 0012198: 2021-01-31
Error loading Gramps database from backup Ошибка загрузки базы Gramps из резервной копии
- 0012217: 2021-02-17 resolved do not restore backed up media files to the home directory
- 0012311: 2021-05-19 Restoring a backup fails with “cannot find” error
- 0012441: 2021-09-24 feedback Protected media storage inside the current tree database folder
- 0012479: 2021-11-17
When I attempt to restore a gpkg backup that has media included I get this error.
- 0012574: 2022-02-21 Import database FileNotFoundError
- 0012664: 2022-07-19 Gramps package import won’t work if media directory already exists
There is a 7zip version for linux called p7zip… it’s a console tool, I have never tried it, but you can download it from here: Download
I agree when it comes to media handeling…
It should have been a “do you want to import media” without any deleting… if there were media files with same names and file size, you should be asked what to do for each file… better with 2000 duplicates than one wrongly deleted file…
I also agree with the rest you write on this topic…
1 Like
Thanks! Your suggestions for adding another application for the software toolbox are always very useful.
