• Hi,

    I’m trying to place signal messengers backup on a webdav-mount. The backup process starts, but is then somehow aborted. I can’t say if it is signals or davx5 fault.

    Thanks in advance, Jens

    davx5-debug.zip

  • developer

    @jmue Hi,

    It seems to be a Signal problem (backup only works on local file systems): https://github.com/signalapp/Signal-Android/issues/10258

    Please follow up there.


  • @rfc2822
    I tested some more settings, here are the results:

    • Nexcloud-SAF: does not work. That doesn’t surprise me because nextcloud uses a upload queue and so the temporary file is not uploaded immediately. If signal creates a temporay file for upload process, renames the file and then queries for the file, the nextcloud android app may be still uploading the file with the original name.
    • Davx5-SAF [Magentacloud]: does not work.
    • Davx5-SAF [Nexcloud]: does work! It seems that there are only problems with a few providers.
  • developer

    @jmue said in [webdav-mounts] signal backup:

    Davx5-SAF [Magentacloud]: does not work.

    Thanks for the update!

    So I’d need a possibility to test with Magentacloud. Unfortunately we don’t have an account.

    Edit: I’ll try to create a Magentacloud account to have a look.

  • developer

    @rfc2822 Found it. Signal (or the DocumentsProvider client on its behalf) checked the file size, 0 bytes were still cached in DAVx⁵ and so they thought there was a problem and deleted the file.

    Works when DAVx⁵ sets the file size in the cache after a successful upload.

    So this should work with the next release.


  • @rfc2822
    Good catch, updating the internal database with the uploaded content-length seems correct. But the behaviour is still weird. Signal can now even successfully backup to Magentacloud, but the created backup files are empty. Did you observe that too? This is not the case for Nextcloud. It looks like Magentacloud is the german technology benchmark to beat (in a negative sense 😂 ).nextcloud.jpg megentacloud.jpg davx5-debug_1.zip

  • developer

    @jmue I think the backup had a correct size when I tested it. Will try again.

  • developer

    @rfc2822 You’re right, its 0 bytes and it’s complicated. I think it can’t be fixed easily. 😕

    Signal writes the backup, closes the output stream and immediately renames the file. However, the WebDAV PUT requires some time, and because the write operation is asynchronous, the renaming doesn’t wait for it.


  • @rfc2822
    Am I correct in assuming that you are passing on the output stream directly to the input stream of the PUT request? So there is no byte-buffer-caching on your side. As I understood you, there is still a small window of time where is filedescriptor is closed but the PUT is still ongoing.

    Some maybee ugly workarround may be to have filelock table (until the PUT request finishes) and delay copy/rename/move/delete operations?

  • developer

    @jmue said in [webdav-mounts] signal backup:

    @rfc2822
    Am I correct in assuming that you are passing on the output stream directly to the input stream of the PUT request? So there is no byte-buffer-caching on your side.

    There’s a 1 MB buffer, but that’s not the problem.

    As I understood you, there is still a small window of time where is filedescriptor is closed but the PUT is still ongoing.

    Exactly.

    Some maybee ugly workarround may be to have filelock table (until the PUT request finishes) and delay copy/rename/move/delete operations?

    Yes, I have thought about that. Surely much work for little result, and such things look to me as if they would cause 10000 new bugs. But maybe one day…

Similar topics

  • 5
  • 6
  • 8