So there is really no "master": every access method is as good as the other one. The way I look into this system (and possibly many others too) is that sync client is one of different access methods to the cloud storage system. It might be that this case requires a special approach it is of course a matter of (interesting) discussion but I would say that both points of view ("server is a master" and "client is a master") are not correct. Would remote deletes be propagated locally in a correct way? What about propagating local and remote moves - would that work or not? Local deletes would be reverted back to the server state. Conflict files would be created if either local or remote file was changed. What really needs to be checked is how good the reconciliation procedure in absence of local state information really is.
If user decides to sync this again then the procedure should be to reconcile this directory with the corresponding server directory without using any previous state remembered in the sync client db file (same scenario as if you deleted local client state db file). I think what should happen is that simply the client should forget about this directory and all its contents. What about when you move files and directories around? Etc. What do you expect when you bring this folder back to sync? Your deletes propagated to the server or your deletes reverted and files downloaded from the server? What about if you add a new file to a folder which was taken off sync? You don't want to lose that file, right? So in this case you want your local change (file addition) to be taken into account. However to understand what is the desired behaviour is tricky: suppose you take the folder off the sync and then remove its content locally. Sync client should not really delete anything behind user's back via the "choose what to sync" option. The user can delete anything they want to, if they choose to. The safe assumption is to leave local folders as is. This morning I opened up my computer again and the first thing OwnCloud did was to delete the folder! This is completely unintuitive and unwanted behavior: there should be no situations where OwnCloud deletes local folders without asking the user first. Unnecessarily complicated, but I got what I wanted - or so I thought. I shrugged, copied the folder into a different location, stopped sync and copied the folder into the proper location again. This felt like a weird assumption: surely I could remove the folder if I didn't want it locally? This seems like a completely separate thing from whether I want it synced across machines. I noticed that stopping sync would mean that the folder would be deleted. I ran into this last night: I wanted to stop syncing a folder that changes often and is backed up by git. I would like this to be made a priority - the current behavior is incredibly destructive and unintuitive. Storage backend: file system Client configuration
Uncheck subfolders that you don't want to synchronize anymore.Later click on "Choose What to Sync" for that folder.Set up a folder to be synchronized with the server.Actual behaviourĬurrently there seems to be no option to do that (apart from removing folder A completely and setting it up again while unselecting subfolder A.B) so it would be great if the user could somehow choose whether local files are to be deleted. Just because I don't want something to be synchronized anymore doesn't necessarily mean I want it to be removed from my local machine. If I select a folder ("A") to synchronize with server and later decide not to synchronize one of its subfolders ("A.B"), I might not want local files to be deleted.
0 kommentar(er)
