Signal-android: Backup generates and renames backup file but deletes it (Nextcloud)
- [x] I have searched open and closed issues for duplicates
- [x] I am submitting a bug report for existing functionality that does not work as intended
- [x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
- [x] This isn't a feature request or a discussion topic
Bug description
For external storage I chose a folder in Nextcloud. This results in the storage location being displayed like "-123456789/12345" and the backup failing with "Renaming temporary backup file failed!" according to the debug log. I have no SD cards.
See also:
https://github.com/signalapp/Signal-Android/issues/7763
https://github.com/signalapp/Signal-Android/issues/7692
It appears the file is successfully created and renamed, but Signal decides to delete it anyway, before Nextcloud can upload it:
Nextcloud app:
Nextcloud web interface:
Steps to reproduce
Turn on external backup. Select Nextcloud folder. Run backup.
Actual result: Backup takes a while and eventually it stops and says "Last Backup: Never".
Expected result: The backup completes successfully or gives me an informative error message.
Device info
Device: Xiaomi Mi 9T (davinci)
Android version: 10
Signal version: 5.0.0
No SD cards mounted.
All permissions for write access are granted.
mueslo
All 10 comments
for debugging purposes, did you try to keep Nextcloud disabled while Signal performs the whole backup operation?
it feels like some kind of conflict happening when Signal renames the .tmp file, which should be excluded from syncing in Nextcloud default config , but appears not to be ignored in your setup.
I think the .tmp file should not start to upload until it is complete and renamed to .backup
Feels like a misconfiguration in Nextcloud instead of a problem with Signal
Lion-box
on 6 Dec 2020
for debugging purposes, did you try to keep Nextcloud disabled while Signal performs the whole backup operation?
it feels like some kind of conflict happening when Signal renames the .tmp file, which should be excluded from syncing in Nextcloud default config , but appears not to be ignored in your setup.
I think the .tmp file should not start to upload until it is complete and renamed to .backupFeels like a misconfiguration in Nextcloud instead of a problem with Signal
You cannot configure this behaviour in the Nextcloud Android app, so it can't be a misconfiguration of Nextcloud.
Also, I don't think it is feasible to "keep nextcloud disabled". The destination only exists due to nextcloud, since it is not a regular file system destination.
mueslo
on 7 Dec 2020
...since it is not a regular file system destination.
which could easily be the reason why Signal appears not to be able to properly rename the file.
I'd suggest to try to backup to a "regular" folder and add that folder to Nextcloud Files
Lion-box
on 7 Dec 2020
You seem to have a misunderstanding of how Nextcloud on Android works. It doesn't just synchronize the underlying file system like on PC, it only synchronizes on demand via some special purpose filesystem or the app itself. So if I save it on the normal FS, it won't be automatically synchronized to Nextcloud.
Signal supports selecting Nextcloud as a backup target in the location picker via some sort of special purpose FS. So it should be fixed (or not supported in the first place). Telling me to just save it to a regular file system location is pointless, as that is what this issue is exactly NOT about.
mueslo
on 7 Dec 2020
Good timing, I _just_ ran into this. I set up Nextcloud on my own server, and checked that it works with the android Nextcloud app. I also successfully saved a file from another unrelated app using the Nextcloud SAF provider. When I tried to make a Signal backup manually, I saw:
- Signal started counting up messages (presumably it's writing to a local file managed by the Nextcloud app)
- Nextcloud popped up a notification saying that it was uploading the file
- Very quickly, the notification disappeared, no error was displayed, but the Signal app said no backup was made. This happened faster than the file could plausibly have been uploaded.
- No files are present in Nextcloud. The Signal debug logs contain a message
LocalBackupJobApi29: Backup failed. Deleted temp file.
The Nextcloud server logs have:
"PROPFIND /remote.php/webdav/Signal/ HTTP/1.1" 207 1421 "-"
"PROPFIND /remote.php/webdav/Signal/ HTTP/1.1" 207 1648 "-"
"PUT /remote.php/webdav/Signal/.backupaeb93825-ebe5-456f-a881-15030cc55490.tmp HTTP/1.1" 201 872 "-"
"PROPFIND /remote.php/webdav/Signal/ HTTP/1.1" 207 1421 "-"
"PROPFIND /remote.php/webdav/Signal/ HTTP/1.1" 207 2595 "-"
"GET /remote.php/webdav/Signal/.backupaeb93825-ebe5-456f-a881-15030cc55490.tmp HTTP/1.1" 200 835 "-"
"GET /index.php/204 HTTP/1.1" 204 1172 "-"
"HEAD /remote.php/webdav/Signal/signal-2020-12-07-16-03-00.backup HTTP/1.1" 404 537 "-"
"HEAD /remote.php/webdav/Signal/.backupaeb93825-ebe5-456f-a881-15030cc55490.tmp HTTP/1.1" 200 816 "禄
"MOVE /remote.php/webdav/Signal/.backupaeb93825-ebe5-456f-a881-15030cc55490.tmp HTTP/1.1" 201 668 "禄
"MKCOL /remote.php/dav/uploads/nc/6a3655c4ed783baa83f4f1f438593ae4 HTTP/1.1" 201 548 "-"
"PROPFIND /remote.php/dav/uploads/nc/6a3655c4ed783baa83f4f1f438593ae4 HTTP/1.1" 207 1481 "-"
"DELETE /remote.php/webdav/Signal/signal-2020-12-07-16-03-00.backup HTTP/1.1" 204 492 "-"
Watching the filesystem on the server, it looks like the file never actually gets uploaded.
My Nextcloud "activity log" looks roughly like the one that @mueslo posted.
So it does look like Signal is incorrectly determining that the backup failed, and then deleting the file, before it can get uploaded to Nextcloud. It seems like this might be due to incorrect usage of the storage access framework, perhaps assuming a level of consistency that's true for the local filesystem but not for remote SAF providers?
Nextcloud version 3.14.1
Signal version 4.79.3
dnr
on 8 Dec 2020
We really need debuglogs from Signal to do anything. FWIW all we do is write a file to the location specified. If we're aborting, it means we're getting an IOException during write. Logs would let us know specifically what's happening.
greyson-signal
on 8 Dec 2020
mueslo
on 8 Dec 2020
Looks like we aren't properly logging the specific exception :facepalm: I've added additional logging to 5.0.3, apologies. That should be going to beta later today, and to production later this week. Once you get that release, if you could post another log after a backup fails, that'd be very much appreciated. Thanks again!
greyson-signal
on 8 Dec 2020
Will do. Thanks for investigating.
mueslo
on 8 Dec 2020
@greyson-signal here is the same log on signal 5.0.4: https://debuglogs.org/899dfc8d5c5bc502a11c16c211050301c2dd44eca7713f6f6a4c4869a9fa2a57
Doesn't seem more verbose to me, though.
mueslo
on 13 Dec 2020
Related issues
notthematrix
路
3Comments
5boro
路
3Comments
halb9
路
3Comments
kwlg
路
3Comments
Dyras
路
3Comments
Most helpful comment
Looks like we aren't properly logging the specific exception :facepalm: I've added additional logging to 5.0.3, apologies. That should be going to beta later today, and to production later this week. Once you get that release, if you could post another log after a backup fails, that'd be very much appreciated. Thanks again!