Android: [3.5.0 RC2] autoupload fail rewriting files

[ffuentes]

Actual behaviour

• Get conflict and can't upload new version of files.

Expected behaviour

• Upload new version of files.

Steps to reproduce

1. Setup autoupload for a folder with files that can be partial like mp3s or audio like audio recorder o call recorder.
2. The app detect the created file after the recording has beggining and upload successfully to the cloud.
3. After the audio is finished the new files is bigger. Then it tries to upload the new version but fails giving a conflict message.

Environment data

Android version: 3.5.0 RC2

Device model: Xiaomi Mi Mix 2

Stock or customized system: Stock

Nextcloud server version: 15.0.2

This bug does not happend in previous version < 3.5.0. On previous version, the app successfully upload the new version of the file.

[AndyScherzinger]

@tobiasKaminsky could we maybe run into issues due to the dynamic chunking? Else I can't recall any changes to auto upload within the 3.5.0 release.

[nextcloud-android-bot]

GitMate.io thinks possibly related issues are https://github.com/nextcloud/android/issues/2295 (0), https://github.com/nextcloud/android/issues/3551 ([3.5.0 RC1 and RC2] Cannot upload bigger files any more), https://github.com/nextcloud/android/pull/3549 (Bump to 3.5.0 RC2), https://github.com/nextcloud/android/pull/3509 (3.5.0 RC1), and https://github.com/nextcloud/android/issues/3015 ([3.3.0 RC2] missing avatar fetching).

[bjo81]

I have this issue also with a file which is created by a banking app. After the file changes, it should be autouploaded again just as a backup.

[tobiasKaminsky]

The first reason seems to be that the upload is started when the file is still being written to. Maybe there is a way to check if this file is still "open" by another app.

The second issue seems to me unrelated, as I understand that backup.zip is uploaded on day 1 via AutoUpload, changed the next day, and should be uploaded & overwritten via AutoUpload.

[ezaquarii]

The first reason seems to be that the upload is started when the file is still being written to. Maybe there is a way to check if this file is still "open" by another app.

There is no reliable way of doing that. But you can monitor mtime and size and start uploading only after period if inactivity. Not perfect, but looks like a quick win.

[bjo81]

This issue also exists now with the released 3.5.0.

[tobiasKaminsky]

@bjo81 which app is that?
In my opinion it should go this way

• start recording
• app saves it in a temp folder
• after finishing file should get copied in total to destination

• same is camera app from google doing
• same we do for download, so that there are no partial downloads
• maybe you can(?) cancel recording inbetween, which then would lead to a half uploaded file

There is no reliable way of doing that. But you can monitor mtime and size and start uploading only after period if inactivity. Not perfect, but looks like a quick win.

We could do this, but this might also result in new questions/problems, e.g. timeout, how long to wait, …

[bjo81]

I do no recording, in my case it's "Banking4" which does automatic syncing every hour and stores a file in /Documents. Nextcloud should upload the updated file and refuses it due to "conflict", with <3.5.0 it was simply overwritten.

[tobiasKaminsky]

So I did this to test

• set up a custom folder in auto upload
  
  
  
  • /sdcard/download to /download (on server)
  
  
  • no wifi
  
  
  • keep source file in folder
  
  
• I created with amaze "test.txt"
• I edited this file and added some text
• as I do not wanted to wait for auto upload I went into NC app -> upload, pull to refresh to force rescan
• file was uploaded fine
• I used amaze to edit file again
• I again triggered rescan of NC uploads
  --> if file is > 1mb it fails with described "conflict" error

[tobiasKaminsky]

https://github.com/nextcloud/android-library/pull/258