Some error messages leave a bit to be desired #830
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#830
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
I'm doing backup of a few hosts with "largish" (more than 500GB) amounts of data to back up.
This is "initial backup sessions", started with
Some of these backup sessions terminate with an error message which is "less than readable" and which are also "less than concise" in terms of revealing the actual underlying root cause of the error, in that the textual representation of the Unix
errno
value which gave rise to the error is nowhere to be found in the error message.Steps to reproduce
I don't know what is actually causing this issue, since the Unix errno value is not revealed. In this concrete example, the error message was emitted after about 178GB of data had been transferred to the repository.
Now, as I understand it, checkpointing at the server end will ensure that "all is not lost", and a re-run will not have to start from scratch, so that's something, at least...
Actual behavior
See the uploaded file. The error message is in essence
and
which is ... less helpful than it could be in revealing the actual underlying problem.
Expected behavior
The actual underlying
errno
value ought to be revealed in the error message, instead of an application-specific exception value and an applicaiton-specific stack traceback.Other notes / implementation ideas
(nothing here above what's stated above)
borgmatic version
1.8.5
borgmatic installation method
Via pkgsrc,
pkgin in py310-borgmatic
.Borg version
borg 1.2.6
Python version
3.10 (python310-3.10.13nb4)
Database version (if applicable)
N/A
Operating system and version
NetBSD/amd64 9.3
This looks like an internal Borg error, so you might consider filing a ticket with the Borg project after checking the existing issues.
In terms of borgmatic's handling of this Borg error, it does show Borg's
errno
in the form of... returned non-zero exit status 2
, but that's just Borg's generic exit code and has nothing to do with the specific FD exception.Note that Borg 1.4 does make more specific error codes available to borgmatic, but Borg 1.4 hasn't had a stable release yet.
I hope some of that helps!
Closing for now, but please let me know if you have any other feedback on this! Thanks.