Have you actually looked at the uncompressed version of the backup file?
The .gramps is a compressed file using the same name as the uncompressed .gramps file which is actually an XML file.
On Win10 I use 8 Zip Pro (Windows Store) to extract the inner file. When you launch 8 Zip Pro it will allow you to Open Archive. The inner file (same name) will be presented. You can drag-n-drop the inner file to a different folder on your computer. Once extracted, this is an XML file that can be read by any text editor.
Seeing if actual information is written to the file and where it may have stopped processing may offer up new clues.
I’m using the desktop short cut icon. I wasn’t aware there was such a thing as grampsw. I looked at the properties for the shortcut and it shows target as “C:\Program Files\GrampsAIO64-6.0.6\grampsw.exe” So, no, I’m not using gramps.exe as far as I know.
Just trying to come up with something! anything! that will explain the issue.
If the backup is aborting while processing, it explains why the database remains locked while if you just open and then close without changes resulting in no backup on exit properly clears the database lock.
Oh, my! It isn’t you that is silly, it’s me. I am so embarassed. While C has lots of space, my flash drive where I save the backups was too full. Dave triggered me to realize where the problem must be so I deleted the extra backups and everything works perfectly. I’m so sorry for taking everyone’s time (especially you, Emyoulation) but this leaves me with a suggestion…
It would be a good idea to have a warning come up telling us there is not sufficient space when trying and failing to backup. Nothing alerted me, not with the failed auto or the manual backup. Would that be a simple thing to add to the program?
Again, I’m sorry and thank you so much for your persistance and dedication to this fabulous software program.
I prompted Perplexity: for python, are there any capabilities for detecting a “disk full” when attempting to write a file?
Yes. In Python you detect “disk full” via the exception raised on the write/flush/close, not via a special API.
Basic pattern
Wrap your write in a try/except and inspect the exception:
python
import errno
try:
with open("out.dat", "wb") as f:
f.write(huge_bytes) # or multiple writes
f.flush()
except OSError as e:
# On POSIX, ENOSPC = no space left on device,
# Windows: use the errno mapped from the underlying Win32 error
# EDQUOT = quota exceeded (also “out of space” for this user)
if e.errno in (errno.ENOSPC, errno.EDQUOT):
print("Disk is full or quota exceeded")
else:
print("Other I/O error:", e)
Key points:
In modern Python, IOError is an alias of OSError, so you normally just catch OSError.[realpython]
The “disk full” condition is indicated by errno.ENOSPC on most Unix-like systems; quota exhaustion is errno.EDQUOT.stackoverflow+1
The error may surface on write(), flush(), or close(), so you should be prepared to handle it at any of those points.[stackoverflow]
If you want to be very robust, keep track of how much you’ve successfully written so you can resume after the user frees space, then retry from the point of failure once your error handler decides it’s safe.
This thread has been referenced in a feature request:
0012306: Gramps and ‘disk full’ [ sqlite3.OperationalError: database or disk is full ]