Torsten Grote

> I see no reason for an actual I/O error. Maybe the filesystem is corrupted? > As mentioned below, on a second try there was no I/O error. Ok, all...

> Again, as I wrote in the OP, it is NOT sufficient to provide very vague error messages. User should get to-the-point information what exactly went wrong and why. Sorry,...

@eternal-sorrow to debug this, could you send me a file/dir listing of your `.SeedVaultAndroidBackup` folder and a logcat export right after the error occurred? You can do the export from...

Glad you figured it out! We should improve the error message, but it isn't trivial. There may be several backups in this location. Some we can't decrypt, because of wrong...

you should be able to export all needed logs via the UI, tap 3-dot menu at the top right corner on main screen, go to expert settings and then choose...

If you still have the old backups, you could point Seedvault to that location and then select "restore backup". If nothing shows up, export logs right after and cut the...

I resolved a conflict. @t-m-w does this still work as expected?

Looks like there's around `10ms` the system gives us between calling our `NotificationBackupObserver` and killing our service. This doesn't seem to be always sufficient to reach the code path for...

Here we had 5ms: ```ruby 06-20 11:18:36.755 1010168 30423 31899 I NotificationBackupObserver: Backup finished 253/253. Status: 0 06-20 11:18:36.760 1010168 30423 30423 I BackupStateManager: appBackupRunning: false, filesBackupRunning: false, workInfoState: ENQUEUED...

Turns out that my theory that our process simply got killed fast is wrong. We can in fact keep running for quite some time after the backup transport service was...