TW
Well, there isn't much we can do there: - either "crash" and show the traceback (as it is) - this is good because it shows a lot of infos so...
Yeah, that shouldn't result in a traceback. But of course one needs to give an archive name for `delete` as in contrary to borg 1.x that command is only intended...
Thanks for the pointer. Yeah, that's quite a lot already. Missing OSes: - *BSD - Solaris derivates, like e.g. OpenIndiana Not sure about the situation on windows. Would such a...
Another data point: Some years passed since I opened this ticket and availability of and dependency on rust have changed. E.g. I recently had to add rust toolchain to my...
This looks like a RAM issue, please run at least 1 full pass of memtest86+ on your borg client machine. ``` >>> hex(int('u'.encode()[0])) '0x75' ``` So, that is a single...
Isn't mprime rather a CPU load test? My suspicion is that your RAM might be unreliable. Of course it could also be that the RAM is ok and working normally....
Also, please note that the reason why it is reproducible could well be because your repo already contains corrupted metadata (so the corruption event was at `borg create` time and...
Quite some corruption there, so it seems more than the normal, rare, non-ECC RAM bitflip. Guess I would: - fix the hw issue - run `borg check --verify-data --repair -v...
If you don't fix the hw, issues will reappear.
If you do a lot of activity on that machine while memory is not working correctly, you risk all sorts of malfunctions and even persistent corruption, not just in the...