It is the job of the file presenter to decide how best to resolve any conflicts that arise. "Your app is notified of conflict versions through its file presenter objects. BUT: Due to the more integrated way of applications interacting with iCloud in the Apple world, there are more recommended ways to resolve such issues. " Its solution is to make the most recently modified file the current file and to mark any other versions of the file as conflict versions." -> same basic implementation as owncloud. OneDrive / SkyDrive: "the file that was saved last will keep its original name, and the version that has been altered on the other machine will be renamed with the machine's name appended to the filename." -> also according to my S2, as it seems. GDrive: I haven't found any definite information about which of the conflicting files get the tag in the file name. Dropbox: As I understand this, Dropbox has implemented conflict handling according to S2. But on the other hand, cases of data corruption are avoided, which is, IMHO, more important. the change that "by accident" the file with the original name is the file that the user wants to use is lower. This has the disadvantage, that in most cases the NEWER file will be the one the user wants to use in future, but the server file could also be the newer file, and then the user won't "automatically" use the correct file. S2: Always rename the server file to ".conflict.", not the older file (my initial suggestion). However, most cloud sync clients, such as Dropbox, Wuala, Google Drive etc. most sync programs I know (and I know a lot) use such dialogs. Maybe even with an option to show the differences of file contents using diff.). S1: Introduce an (optional) interactive conflict resolution mode, in which conflicts are recorded during sync and at the end of the sync, a dialog is shown with a list of conflicts, in which the user can decide per conflict or for a group or all conflicts, how they are handled (options: use server file, use client file, use newer file, use oder file, use larger file, use smaller file, keep both files and change the server file's name to ".server.". But still, I think renaming a local file should be avoided. Storage backend (external storage): Client configurationĭe Qt version used by client package (Linux only, see also Settings dialog): Client package (From ownCloud or distro) (Linux only):ĭefault: /Applications/nextcloud.app LogsĪh, I see: " The client resolves this conflict by creating a conflict file of the older of the two files and saving the newer file under the original file name." So not always the local file is renamed, but it is always the OLDER file that is renamed. Then you get a feeling how frustrated I was when I finally realized that no data was saved! -) Server configuration (*): Please do, like I did, a LOT of very important changes, about 2 hours of work.
#Removing notecase pro pro#
See, that in NoteCase Pro the changes are not persistent (selecting another note and then the modified note again -> changes are gone!).In NoteCase Pro, file still open, make changes to the file and save (*).Start the owncloud client and let it sync the file, renaming the local version.Make changes to the local version of the file, to also trigger a sync.I have not modified the file on the server or any other client - a server bug? But not relevant here.) Trigger, that owncloud/nextcloud wants to sync the file in both directions (in my case, the reason was, that I moved the entire data repository to a new directory and updated the server for some reason, occ wanted to sync "down" the server version of the file then.a file created with NoteCase Pro ( using the ncdb file format (not the other formats, as they are not SQLite-based!) into an owncloud-synced directory.
Instead, my suggestion would be that the server version of the file, that's downloaded, is saved under the local name ".conflict." instead. The client should not rename local files (because they could be in use). If an SQLite file, that's currently open in its application, is synced and the client resolves a conflict by downloading the server version of the file, saving it under the original file name in the local folder and renames the local file to ".conflict.", the application that uses the file has troubles accessing the file and data is lost. Closed there, because it's a client issue and those should be tracked here, I was told.
0 kommentar(er)
