borg extract: check behaviour on integrity (or other) errors

[ThomasWaldmann]

Assuming there is some issue in the repo storage, like partial corruption, unreadable disk sectors or so - how does borg handle them?

It might be the case that borg extract currently aborts when it hits such a file. More helpful would be to log an error for that file and try to continue. At the end, exit with warning status (1). This is similar to what borg does when creating archives and it encounters problems for single files.

[enkore]

I'm moving this to the 1.2 milestone, since this is not possible atm for IntegrityErrors on the Repository layer for remote repos. I.e. it would need an RPC change and would not work with old servers.

I'll leave the code there (feature/extract-logfail) so when 1.2 comes up we can use that as a basis.

How does borg extract do it now

Abort on first error

[ThomasWaldmann]

hmm, thinking about what's worse:
doing a rpc change in 1.1 (we already have some rpc changes) or being unable to (easily) extract an archive due to some defect repo chunks aborting it here and there.

[ThomasWaldmann]

Hmm, what do you mean by "is not possible atm"? The repository code already can raise IntegrityError at a lot of place and borg.remote re-raises them if that error type comes from the remote.

[ThomasWaldmann]

@textshell see above - how is that after your rpc changes?

[textshell]

hmm, not sure about this. The new RPC should not have changed much. But i don‘t see why this is not possible with the 1.0.x or 1.1.0 rpc protocol looking at it briefly.
One change that might affect this though is that IntegrityError now keeps its details string. But the code doesn‘t parse that anyway. (Maybe we should add more machine readable information there...)

@enkore
Do you remember what prevented the code from working with remote repositories?