I am unable to export or backup Gramps. I always get the following error message whenever I try to export or back up the database, with or without media included, and whenever I specify any directory on my C: drive, including C: or C:\users.
“Errno 2: No such file or directory: C:\Users\xxxx\Documents\Family Tree - Gramps xxxxx_2024-05-05.gpkg”
Version: GrampsAIO64-5.2.0-r1-6167151
Operating system: Windows 11
The solution posted in this report was to make sure the backup folder set in Preferences (menu >> Edit >> Preferences) is the same as the folder you want to use in Make Backup (menu >> Family Trees >> Make Backup).
This is very weird, because I have no such problems in Windows 10 Pro, running on my laptop, and in a VM, nor in Windows 11, which sort of suggests that this may be a rights problem.
And over here, it doesn’t matter where I want to save that backup either, so the idea that you can only create backups in the folder set in preferences does not make sense to me either.
So here’s a question for @david1 : Can you tell us something about user rights on your system? Can other applications, like Word, create files in your Documents folder?
Another question for @david1 : When setting the folder as the save location, did you use the file/folder selector built into Gramps or did you hand type the folder’s address? An error in a manual entry?
I just ran some tests and the location mismatch made no difference on my system. 5.2.2 on Win10 Home. And there was no error after closing and relaunching Gramps. The mismatched file location made no difference.
In my case, the the backup folder set in [Preferences] is exactly the same as in [Make Backup]. The database will still not back up. I used the file/folder selector built into Gramps and did not hand type the folder’s address.
OK, but to me it’s still unclear why this happens on your PC, and not on any of the 3 that I have here. They run Windows 10 and 11, and I see no logic in this, other than that there’s something very weird on yours w.r.t. file permissions.
When you install Gramps, it needs access to your user folder to store configuration files, your database, and any plug-ins that you download. And if any of those would go wrong, I assume that you would have mentioned that here earlier, which suggests that Gramps has rights to data there.
Your Documents and Pictures folders are there too, and I assume that you can create new files there, and change them too. And if that’s the case, what reason can there be that Gramps can’t? And why can it do that here on all my 3 PC’s?
And from here, the only explanation that looks somewhat ‘reasonable’ is one where Gramps did not get the rights that it needs to its work, or when it runs into a problem that’s specific for your country or your language.
And if that’s the case, you may be hiding the problem by not giving us the real paths. And they can be important, because I’ve seen problems with character sets earlier, in my job.
I’d like to try an experiment – clean install Gramps 5.2 on a different Win 11 computer. Then add sample data, and try a backup. If that works, make a copy of the problem database file from the “bad” computer, paste it in the equivalent folder location on the new computer, and see if I can then back it up. I’ll report what happens.
One other thing: Your profile suggests that you’re in Poland. Are there any characters with accents in the name of your personal users folder, or in the name of your database that may also end up in the name of the backup file?
I’m asking, because I know that Gramps makes use of UTF-8 inside the database, but I don’t know how well it works with non ASCII characters in file paths.
Well, I got some pretty interesting results for my experiment. I downloaded and installed Gramps 5.2.0 on another computer running Win 11 and added test data. I was able to backup the database with no problems.
I then copied the grampsdb folder from the “bad” computer and pasted it into the correct folder on the “good” computer. The Gramps database loaded with no problems, and I could back it up without any issue.
I then went back to my “bad” computer and uninstalled Gramps 5.2.0, and installed Gramps 5.2.2. I copied the “good” grampsdb folder from the “good” computer to the “bad” computer, and then opened the exact same database on the “bad” computer. Interestingly, I was unable to make a backup of the database on the “bad” computer.
So my conclusion is there is something wrong with the “bad” computer that prevents me from backing up Gramps, whether it is running version 5.2.0 or 5.2.2. I don’t have the time or technical skills to compare every possible setting on the “good” computer to the “bad” computer to see what might be different.
When you uninstalled 5.2.0, I am assuming you just uninstalled the program files but not any of the user files. Most notably the gramps.ini from the first install was there when you installed 5.2.2.
With Gramps not running, delete from your user files gramps\gramps52\gramps.ini When you start Gramps anew, it will be as if this is the first time Gramps has run on the “bad” computer. Yes, any previous preferences will be lost but more importantly, file locations for backups will be reset to defaults when Gramps recreates gramps.ini.
As you know Gramps is reading and writing to the folder containing your database folders, maybe set the backup to gramps\grampsdb as a first test. Maybe subsequent tests writing backups back through this path list until you can switch from users\XXX\appdata to users\XXX\Documents.
Again, I am just trying to think of anything. I have not yet upgraded to Win11, I am still 5.2.2 on Win10, so cannot experiment with any system variables.
The only thing that I can think of, now that we’ve excluded illegal character in the file paths, is that for an unknown reason, Gramps has no rights to create that backup file, no matter where you point it.
And that’s why Dave and I asked about those rights, and I didn’t see an answer to that, so I repeat the question that Dave asked: Did you install Gramps for all users, or for you, or for another one? That is important, because Gramps runs in a specific context, and if the user behind that context has no rights to create the backup file, you may get an error like this.
I need to add that this is still a bit weird, because you wrote that you were able to copy the grampsdb folder to the ‘bad’ computer. And when you did that, I assume that you did that to its standard location, which is somewhere inside AppData\Local or AppData\Roaming, depending on that computer’s history. And I also assume that Gramps itself had write access to that location, so that you could work on that tree before trying to create that backup.
Can you confirm these things? Are your gramps data files in their standard locations? Did you install Gramps for all users? And if not, how did you install it then?
And one that wasn’t asked yet, I think: Is there a virus scanner running? And if so, what is that? Windows Defender? Do you have an active ransomware protection that might get in the way when an ‘unknown’ program tries to write to your data folders?
Still having this problem on the “new” win 11 computer?
If so, browse to the folder location where you are going to save your backup, and count the characters in the complete file path, including all special characters, spaces etc. and include the file name including file extension.
I have had problems with Gramps being able to read 32-bit file paths on Windows even if it has been enabled in Windows itself.
So, if you have more than 255 characters in the file path, try two things:
Save to another folder
Enable 32-bit file path (you will find a lot of articles online about this, just search for windows 32-bit file path or long file name and long file path in Windows).
Deleting gramps.ini worked perfectly. I am now able to backup and create export on the (formerly) “bad” computer. I suspect the .ini file somehow got corrupted, but now everything works OK.
That’s good news, and I saw that in Dave’s advice, and in his earlier reference to a bug report. And from here, it would be nice to know what line in the file caused the problem, because knowing that might enable us to create a fix.