Backup to USB drive fails, with no useful error message

[Moini]

Hi - first time user of seedvault on LineageOS here.

I first configured seedvault to backup to internal storage, as I did not have a USB drive with adaptor available.

Then I changed the backup target to a freshly formatted (ext4) USB drive, when I found one and attached it with a borrowed adaptor.

However, when I now choose to 'Backup now', all I get is a short flashing up of the backup icon in the notifications bar, which after a couple seconds changes to a warning cloud icon, with a notification that says to tap for more information. However, no other information appears, only the seedvault app opens.

I have no idea how to find out what is wrong. Nor what is wrong. Suggestions for figuring out the cause of the failure are appreciated.

I had activated to backup data, which, after reading the issues here, I have deactivated, but that did not make a difference. Same for 'backup apps themselves'.

---

Update:

After choosing 'USB drive' a second time, it does not show the warning icon, however, the progress bar does not move, it seems to be stuck at the first app already 'bluetooth', and the flash drive seems empty according to the Android file manager.

---

Update 2:

I tried to stop the non-running backup by just pulling out the stick, and seedvault didn't even notice that. Force terminated seedvault.

---

Update 3:

It's now showing the progress bar for the backup at the same time as a 'the backup failed' message. I'm giving up and will look into adb backups for my new device again. This is only eating up my time.

---

Update 4:

Tried the protocol option. Protocol file was created, but is empty. 🤷

---

Update 5:

Formatted the stick from Android. Now it appears to work. Why can't the backup software tell me what is wrong? I was able to read the contents of the drive just fine, there was no indication that it would not work with seedvault.

[grote]

Suggestions for figuring out the cause of the failure are appreciated.

Please attach a log exported from "Expert settings" behind three dot menu on main screen.

Why can't the backup software tell me what is wrong?

Seedvault uses the Storage Access Framework (SAF) to access your drive and that API doesn't provide user-actionable debugging information.

[Moini]

Suggestions for figuring out the cause of the failure are appreciated.

Please attach a log exported from "Expert settings" behind three dot menu on main screen.

See Update 4 from yesterday. The log file has been created, but it was of 0 byte size and empty.

Why can't the backup software tell me what is wrong?

Seedvault uses the Storage Access Framework (SAF) to access your drive and that API doesn't provide user-actionable debugging information.

It could at least say something like 'Could not write to flash drive, check this and this ....'. It doesn't give any additional information at all, despite in the notification claiming that if you click on that, it will tell you more.

[grote]

See Update 4 from yesterday. The log file has been created, but it was of 0 byte size and empty.

That update talks about "Protocol file". No idea what that is. You are the first having issues to export a log file. What ROM / LOS version are you on?

[Moini]

I'm using it in German... thought you spoke German as a first language, too?

[Moini]

This was on LineageOS 21, I think. I moved to 22.1 yesterday. Don't know what version of seedvault they ship.

[grote]

I'm using it in German... thought you spoke German as a first language, too?

I still don't know how people translate every part of the UI in every language I speak.

Don't know what version of seedvault they ship.

Please send a screenshot from the About screen. Does log export work now?

[Moini]

Please send a screenshot from the About screen. Does log export work now?

It's 15-5.2 (hope that replaces the screenshot).

Okay, so,

• re-formatted the USB flash drive with Laptop to use ext4, so it would fail to be writable again, supposedly.
• borrowed the adaptor again
• booted the phone
• found seedvault by typing 'sicherung' in the search (neither 'backup' nor 'seedvault' are found, this is a lineage bug, apparently)
• it had already started to make a backup right after I stuck the USB stick in, and before I was able to access the advanced settings. -> Would really be good to have an option to only make a backup on request, not whenever I put ANY USB-STICK in (the name has changed, it should be a different device for the software, why does it write to this stick? It's the same physical device, but how would it know, if the stick has been re-formatted and carries a different name? Does it save the UID? If so, why doesn't it tell me that?)
• that backup had already failed.
• adjusted the setting for the log file to write. It only gives me an option to 'allow once/this time/whatever you want to translate it to'. Or I can 'deny'. There is no option to 'always allow'.
• and the option to make another one is now greyed out. Yay. Why?
• pulled the stick out and put it back in again, maybe that helps un-grey things? - Nope, but it just tried writing to the unwritable stick again. So it should now have written a protocol, IF it had asked for the correct permission, right?... I suspect the file is empty.
• and it is.

So, things to fix:

• put out an error message that is worth that name when seedvault cannot write. Preferably with some ideas for the user how to fix this ('format the stick from Android' (it being writable is not enough, apparently...), 'check whether it is writable', ...)
• add an option to only make backups on request, and never automatically.
• ask for a permanent write permission instead of temporary.
• not grey out the backup option (unless this is because of the error, but I'm not sure - might be because I just made a backup, and it wants the stick to be pulled out and stuck in again? If that is the case, it seems too restrictive. Let me make a backup when I want to. I might always have the flash drive attached to my device, why would I have to pull it out just to make a backup?)
• check whether seedvault is able to distinguish USB flash drives from each other. I don't want a backup written to a random drive.

Hope it helps. It would certainly have made my life easier.

[grote]

Would really be good to have an option to only make a backup on request, not whenever I put ANY USB-STICK in

The expected behavior is that it only makes a backup to the flash drive, if you had set up this very flash drive for backups in the past and the last backup is more in the past than your backup frequency.

Does it save the UID? If so, why doesn't it tell me that?

Yes flash drives have UIDs.

It only gives me an option to 'allow once/this time/whatever you want to translate it to'. Or I can 'deny'. There is no option to 'always allow'.

This dialog comes from the OS, we have no control over it. Just give it permission to read the log.

ask for a permanent write permission instead of temporary.

not possible as far as I know.

So for the the important question is where is the log? Without log I am not able to help you much nor improve the app. If for some reason, the log export doesn't work for you, please get logs manually via adb.

[Moini]

The log ISN'T WRITTEN INTO. It has a size of 0 bytes.

The file is created when I allow to write to the file 'THIS ONE TIME'.

When the error occurs later, my suspicion is that seedvault cannot access the file to update it with the latest problems. At least that seems like the logical reason to me.

How about allowing it to write to a specific folder instead, if file access is limited to single time access and there is no way to work around that for a single file?

[Moini]

(the log is in the Documents folder, but that is completely irrelevant to the problem)

[Moini]

(and getting it via adb is useless, too. What would you want to do with an empty file anyway?)

[Moini]

To write it in easy-to-understand terms:

If you want to access a file multiple times, to add things to it, you need permission to do that. Personally, I don't care how that is achieved, and also, I don't know about the options. But the way it is implemented in the version I have, it CANNOT work.

[grote]

You are the first one that has a 0 byte log file. So I'd like an adb logcat for the log export and the original issue you are having.

(and getting it via adb is useless, too. What would you want to do with an empty file anyway?)

It isn't useless, because you are not supposed to get an empty file (of course!), but run the adb logcat command, so you can capture the log yourself.

[grote]

But the way it is implemented in the version I have, it CANNOT work.

What makes you so sure? Are you the developer here? As I said, you are the first person with this issue. It worked for everybody else so far.

If you want to access a file multiple times, to add things to it

Thanks for educating me. How would I know otherwise? We are creating a new file for each export and thus only need permission to write to that file once.

[chirayudesai]

There also might be a misunderstanding.

The export log feature in Seedvault exports what's available in that log, just that one time. There's no continuous or ongoing logging feature, to keep things simpler both from a development perspective, and privacy wise.

Any time you notice an issue, if you can get a log just after that as soon as it happened - that log should hopefully indicate what happened, and help us figure out the problem.

When the error occurs later, my suspicion is that seedvault cannot access the file to update it with the latest problems. At least that seems like the logical reason to me.

@Moini so that is not how this feature is implemented. If an error occurs later, you can export a fresh log again, and give that to us.

[Moini]

There also might be a misunderstanding.

@Moini so that is not how this feature is implemented. If an error occurs later, you can export a fresh log again, and give that to us.

Thanks for this helpful comment. I'm quite sure that the first log file I got was actually created in that way, because I only discovered the functionality after the backup failed. But I'll try again next time I have access to that adaptor.