Keep the local file when both cloud and local files are modified

[jkawamoto]

When a local file is modified and then the corresponding cloud file is also modified, CheckStateTask would decide to download the newer cloud file and the local change would be overwritten(#40).

It might happen when a user edits a file in a computer without internet (or with slow network connection) and then edits the same file in another computer with internet.

In such a case, Dropbox (and Evernote) keeps both files and the older file has a name explaining the file was modified more then two computers. I think we should follow the strategy and keep both files.

[kaloyan-raev]

What should be the name pattern used for the older renamed local file?

I guess we should exclude this name pattern from the sync logic as discussed in GooBox/goobox-sync-sia#15

And what about the case if the local and cloud copies are both modifier, but the local copy is newer than the cloud copy?

[jkawamoto]

In Dropbox, the format of the file name is "original file name (user name's conflicted copy modification date)" from their document. How about following this pattern?

Those conflicted copies are also uploaded in Dropbox, maybe so that users can solve the conflict from any computer. Although I don't think it is the best way to follow Dropbox for every issues, but it would be enough for the community version.

It's a good point that the case if the local and cloud copies are both modifier, but the local copy is newer than the cloud copy. Can we keep both files in the cloud network?

[jkawamoto]

Those issues GooBox/goobox-sync-sia#16 and GooBox/goobox-sync-sia#17 are also related. Since our current implementation has some delay between a time when CheckStateTask decides to delete some file and a time when DeleteCloudFileTask and DeleteLocalFileTask actually delete the file, users can modify the file.

[jkawamoto]

I added conflictedCopyPath to Utils in goobox-sync-common to create a path for a conflicted copy.