Feature Request: Handle local<->server file conflicts

[the-sane]

I would like to request that conflicting file management be added to the iOS app.

The Nextcloud Desktop app does this whenever it detects that changes have occurred to a file on both the local client and the remote server between synchronization runs. Information on this is documented here: https://docs.nextcloud.com/desktop/2.5/conflicts.html

While testing and reporting a syncing bug (#904), I discovered that the iOS app doesn't seem to do any conflict resolution in that situation. If you follow the steps outlined below, the iOS app seems to always overwrite the server's copy of a file even if the server contains newer changes that the iOS app hasn't yet downloaded. The iOS app will ignore those changes and upload its own locally changed copy without notifying the user that data on the server is being lost.

I would like to see the iOS app handle conflicts similarly to how the desktop app handles them. The desktop app notifies the user that a conflict exists, then proceeds to download the server's copy of the file alongside its own local edits. The server's copy takes priority, meaning it maintains the original file name while the local copy is renamed using a timestamp to differentiate the files. For example, mydata (conflicted copy 2018-04-10 093612).txt It is then left up to the user to decide which version should be kept.

The only difference I would like to see in how the iOS app handles conflicts vs how the desktop app handles conflicts is I believe the iOS app should upload both conflicting copies of the file to the server by default. The desktop app currently suspends syncing of both files, assuming that the user wants to deal with the conflict locally on the desktop before syncing resumes. On a mobile device, however, we should not make this assumption. The user may want to analyze the conflicting files on a different device (ie. a desktop with a larger screen), so we should make both copies available to do so. It seems the rationale behind suspending syncing on the desktop app is to avoid confusing other users in a shared folder situation. This seems like a valid concern so perhaps an option should be provided to disable uploading conflicts.

Steps to reproduce

1. Prepare a test file. I created a file on my desktop and viewed it within the iOS app to make sure it was locally cached there.
2. Put your iOS device into airplane mode and disable wifi. This simulates a situation where you have no service and only have access to the locally cached version of this file.
3. Edit the file on your iOS device.
4. Edit the file on your desktop.
5. Disable airplane mode on your iOS device.
6. At this point, by viewing the file on your Nextcloud server via the web interface, you can see that your iOS device ignored the edits that were uploaded to the server while the iOS device was in airplane mode. It uploaded its own edits, overwriting the conflicting edits on the server.

iOS version

12.3.1

App version

2.23.7.9

Server configuration

Operating system:
Ubuntu Server 18.04

Web server:

Database:
mysql 5.7.26

PHP version:
7.2.19

Nextcloud version: (see Nextcloud admin page)
16.0.2 installed from snap

[the-sane]

@marinofaggiana I wanted to elaborate with a specific use-case on why the potential data loss with this is a severe and breaking issue for me. Without handling file conflicts on my iOS devices, I'm discovering that Nextcloud is not a reliable place to store my notes. Here's my situation:

I have migrated all of my notes to Nextcloud and make regular edits to to-do lists, reminders, etc. on my iPhone, iPad, and Linux desktop. I have about 50 markdown text files in various subfolders, some edited hourly or daily and others less frequently. I also often travel through areas with weak or no cell service, meaning sometimes I am making edits to local files which are older than the copy currently on the server. I may or may not be aware that I'm editing an out-of-date file at the time, since often times these notes documents can be quite long. Here's a common use-case:

• I have a to-do list with things I need to remember to do this week. It has a lot of stuff on it.
• I add a couple items to the list one morning, then get in my car and travel somewhere
• While I'm out, I remember something else I have to do and add it to the bottom of the list. But I'm traveling through an area with a very weak cell signal, so the new edits from this morning haven't been downloaded.
• I return to an area with a stronger cell signal, and the app uploads my edits.
• Because there's no conflict management, the app disregards the newer data stored on the server and overwrites it with the local edits I just made. This means I've lost the reminders I added this morning and the data loss is synchronized to all my other devices.
• Unless I realize what happened, those notes are gone. The only way to recover them is to somehow realize what happened and manually compare different versions using the Nextcloud web interface. This is not an easy process if there have been several edits to a single file.

It is critical for me that the server-side copies of these note files are never overwritten by outdated versions on my mobile devices. There are many areas where I live with weak or no cell service, so it can't be assumed that the local data on the device will always match what the server has when I'm editing a file. I understand that this probably involves a significant amount of effort to add, but I wanted to make it clear why I believe it is important. Thanks!

[daCaPo]

In this context, it might be worth to consider the case when there is NO conflict: When the file has only been updated on the mobile device, it should just been overwritten upon manual upload. Currently, filenames are supplemented by an increment counter, which is very annoying when the user just wants to save the update.

[the-sane]

@daCaPo

Currently, filenames are supplemented by an increment counter

Can you elaborate on this? In my use, no duplicate files with incremented counters have been created. A file edited on my iOS Nextcloud always replaces the server's copy.

[daCaPo]

@the-sane
My steps to reproduce are as follows:

1. Download file "myfile.ext" via Nextcloud client (Nexcloud for iOS 2.23.7.9, Server 16.0.3)
2. Export this file to the external App for editing ("open with...").
3. Export the file back to Nexctlouc via "Copy to 'Nextcloud'" (file of same name still exists in Nextcloud folder)
4. Exported file is stored in Nextcloud as "myfile 1.ext".

When I use the button "Nextcloud" instead of "Copy to 'Nextcloud'" upon export from the third-party app, the filename is supplemented with date and time instead of " 1".

Expected behaviour would be to be asked if the original file shall be replaced or the new one stored with a new (supplemented) name.

[the-sane]

@daCaPo Oh that's interesting. My testing only included editing text files using the built-in editor, not a third party editor. It makes sense that a manual import might be treated differently from automatic syncing, but I completely agree with having the app prompt the user for a replace/rename option in that situation.

[the-sane]

Based on the info in nextcloud/android#343, Nextcloud's Android app handles local<->server file conflicts

I get a popup telling me the local version is in conflict with the distant version.

https://github.com/nextcloud/android/blob/5d8dd742ef9bc83ecb95ec7db7fe7af4eedd49cd/src/main/java/com/owncloud/android/ui/activity/ConflictsResolveActivity.java

https://github.com/nextcloud/android/blob/bf517356335e71d40853cb15a13f384248abdd70/src/main/java/com/owncloud/android/ui/dialog/ConflictsResolveDialog.java

[the-sane]

I looked into it serverside hoping there might be an api to help handle this, but it seems it's left up to the clients to figure out server file conflicts on their own.

In any case, I've confirmed that the official desktop, android, and even the beta windows clients all deal with file conflicts, so iOS seems to be the only one left out.

[the-sane]

I have spent some time thinking about the logic flow for this and created the following flowchart. Hopefully it's helpful.

I tried to include the issue raised by @daCaPo where editing files in an external app treats them as new files and, therefore, doesn't handle updating them.

I'm looking for feedback in case I missed any possible scenarios:

[marinofaggiana]

@the-sane soon read this :-) thanks

[daCaPo]

I just stumbled over another issue that's closely related to the @the-sane 's flowchart:

1. Download a file on the iOS device
2. Rename the file on the server
3. iOS client won't detect the name change, but download the file again. That might become quite expensive for large files.

Expected behaviour: Detect the name change and just rename the local copy instead of downloading it again.

[the-sane]

I confirmed that the desktop client handles server-side file renames as @daCaPo describes, without re-downloading the entire file. This means the server supports the desired behavior.

It took a bit of thought to work that into my flow chart but I think I got it. Please try to think of any scenarios where this would fail to do what we want, or if there's a simpler way to do it: