Gramps 5.1.6 on Windows 10. 64-bit.
My computer started taking a long time to boot and I decided to rebuild it. When I installed Gramps again I can’t import the previous file that I used for several years. There is always this problem with any file I try. I tried to install the previous version of the program but it does not help, when I do the actions required by this error (I delete this folder), another problem occurs Error extracting into c:\users\file name.gpkg.media. I am very sorry that this happened, I hope that someone had a similar problem and knows how to solve it. I’ve been working on this project for 5 years, I can’t lose it.
The restore with images can be complicated. I prefer to restore the Tree and images (media objects) separately. That feels more controllable.
The 1st step of a restore (via import of a .gpkg file) is to expand the tree and media data into a temporary folder. Since the target folder still exists after you aborted the process. This creates a stumbling block for import tool.
If you look in that temporary folder, you’ll see a data.gramps file (which is the Tree data without the media) and a folder structure.
The import feels more responsive if using that data.gramps file rather than the compressed .gpkg file. This might be because there is one fewer decompression cycle. And it isn’t chewing on all that media at the same time.
After importing the data.gramps file, you can extract the Media Files in a subsequent process. You can extract the media object directories from the .gpkg file with 7zip with a high confidence. And the Media tools let Gramps re-link all the files without doing the process manually. So you can clean up (flatten) the folder hierarchy and set the restore folder as your relative media path.
You can try to modify python module gramps/plugins/importer/importgpkg.py
like in the following:
https://gramps.discourse.group/t/create-a-data-recovery-category/4504/6
1 Like
Looking from here, I think the 1st priority should be to understand what’s going on. For example, when the user reports that Gramps can’t write to C:\users\fine name …, my 1st reaction is, that this is quite logical, because in a normal setup, Gramps has no right to write anything to that folder. It can create things inside C:\Users\enno, because that’s where I have rights as a user.
My 2nd reaction is, that to get any further, the user needs to confirm what I think, or prove me wrong, by posting specific information, preferably with screenshots, so that we can see what the actual file names are. And I ask that, because I know that it is very hard to help someone, when the information is vague. When I was on duty to help colleagues that used the software that I contributed to, my 1st question was always: What did you do? And I asked that, because whatever the software does, right or wrong, most times it is triggered by the action of an innocent user. And I’m not there to blame him, but I need to figure out where his actions differed from what I thought that a ‘normal’ user would do, or where they may have hit some limit imposed by the system, or a bug, that makes Gramps try to write to a folder that it should not access. And in theory, there is also a chance that expanding the package, that may contain files with absolute paths, leads to paths that are longer than Windows can handle.
So here’s a new question to @rhdt : Can you tell us what happened exactly?
I’ve recently performed a format on my Ubuntu PC and had a .gpkg backup file. I experienced the same error trying to import the file and I’ve ended up changing the file extension to .gramps and it works fine. You might delete some of your media by doing so, so please do this to a copy of your original file.
I hope that helps! Happy Holidays!
1 Like
Changing the file extension is a simple workaround. Thanks for the suggestion!
One thing: the media files are not deleted when the extension is changed from .gpkg to .gramps. The import simply does not look for anything beyond an uncompressed XML file or a compressed .gramps file.
Changing the extension back will make the import look for those additional files again.
1 Like
I have the same problem.
I’ve last edited and saved my gpkg database in 2022, under version AIO64-5.1.5-1. Now I’ve installed Gramps AIO64-5.1.6-1 and when I try to import my family tree, I get the error message:
“Error extracting into c:\users\[…]\my_familytree.gpkg.media”
What could be the problem? Gramps really does not help with this error message. The my_familytree.gpkg file starts like this:
0 HEAD
1 SOUR Gramps
2 VERS AIO64-5.1.5-1
2 NAME Gramps
1 DATE 7 JUL 2022
…
That’s not a GPKG file. It’s GEDCOM.
Rename it to .ged, create a new tree, and import it.
1 Like
Ok, thanks, that helped. I wonder how it was exported to a .gpkg file with a GEDCOM format. How come I have exported it in GEDCOM format with .gpkg extension? Is it possible through the save or export procedure from under Gramps? I certainly have not changed the file extension after exporting (or rather saving) my database a year ago.
The only thing that I can imagine is that you selected an existing file when you did a GEDCOM export, and the file selector was set to show all file types. and not just *.ged.
It is a bit of a waste, because Gramps can’t export everything to GEDCOM, so you’ve lost some Gramps specific data, like shared events, your place hierarchy, etc.
If you’re still on the same system as then, you might have more backups, like the ones that Gramps makes on exit, and maybe even an old grampsdb folder.
Yes, that is very well possible. I have always found Gramps rather not user-friendly, especially when it comes to import/export. Rechecking all my backups, it seems that the export-to-gedcom happened in 2015, as the previous backup is indeed in zipped gpkg (and not only by extension). Is there a way to import my 2014 gpkg formatted data AND merge the 2022 gedcom data into it?
In theory, yes, but it is a lot of work, because Gramps has no automatic merge for persons that are 100 % identical, at least not when imported via GEDCOM. And if you have different generations of the same tree, you often have loads of identical persons.
I know a few tricks that can help, but they may still require a lot of work.
Thanks Enno for giving prompt replies. My database is really not that big or complicated (100+ people only, no media attached), I may be able to do the merging by hand. What I need to now is what is definitely lost when a Gramps database is converted to GEDCOM. Media files only? In this case, I likely have not lost anything significant.
There’s a wiki article outlining the losses with GEDCOM
You’ll want to look at the Isotammi addons too. Their project deals with merging constantly. The MultiMergeGramplet alone will save you a lot of time.
Can the Isotammi addons merge persons? That would be nice for persons that have the same ID and vitals.
This is something that was easy with PAF, because that program can merge on UID, and will automatically merge all persons that have the same UID and vitals.
Is the UID is perpetuated if another Person exists with that ID? If so we can ask Kari to enhance the People category’s MultiMergeGramplet awareness of that for automated merging.
Well, there are a couple of ways to act now, and one is, that if you accept the losses that come with a GEDCOM export, that you just import the GEDCOM, because it’s newer. You will then loose your place hierarchy, and you will also have problems with surnames if you split those. They are exported with a comma between them, and the importer does not know that.
I prefer to avoid merging full databases, because it’s so boring, that it’s likely that I make mistakes. My brain sort of shuts down then, and that’s a real danger.
There are a couple of tricks though, to make things easier, and one is that you create a GEDCOM file from your latest tree that you still have in Gramps format, and compare that with the latest GEDCOM that you found. You can do that with WinMerge, and it can work quite well in this situation, because both GEDCOMs are exported from the same tree, and identical persons have identical GEDCOM IDs. And since GEDCOMs are sorted by ID, WinMerge will quickly show you where you changed data, and where you added new persons, and if you’re GEDCOM smart, you can also see how they relate to existing persons.
This trick will only work if you didn’t renumber persons between exports. You will also loose the chance to match by ID if you import the new GEDCOM into the old tree, because in that case, Gramps has to renumber the imported IDs to make sure they’re unique.
If the number of changed and added persons is small enough, you can also import the new GEDCOM into a new empty tree, and add tags, based on what you see in WinMerge. You can then export all tagged persons, and import those into your old tree. Doing that makes the number of required merges much smaller, but you may have a problem finding out where to attach new persons, because if you export tagged persons, all relations to persons without tags are lost.
And for that case, there is another trick, because you can add a filter that includes all parents, spouses, and children of the tagged persons. And that will add persons that already exist in the old tree, and their relations to the news ones. and when you import this larger data set into the old tree, merging identical persons will automatically attach the new ones to the existing ones. I often use this trick when I import new brances from FamilySearch, and I also tried it on trees sent to me by a fellow user in England, where 26 persons were added on a grand total of 1822 people. Exporting all changed and new persons gave me a dataset of 88, of which 62 needed to be merged, and that’s much less work than merging the whole thing.
1 Like
Yes, but it only works if you have one. And Gramps does not create UIDs. It’s something that works for me, because most of my persons once lived in PAF, and all persons that I download with Ancestral Quest and RootsMagic also have UIDs. And I also added a tool that generates UIDs to people that don’t have them.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.