owncloud
Unchecking synchronized subfolder without local delete
Expected behaviour
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. 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.
Actual behaviour
Currently 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.
Steps to reproduce
- Set up a folder to be synchronized with the server.
- Later click on "Choose What to Sync" for that folder.
- Uncheck subfolders that you don't want to synchronize anymore.
Server configuration
Operating system: Ubuntu 14.04 Web server: Apache Database: SQLite PHP version: 5.5.9-1ubuntu4.5 ownCloud version: 7.0.2 Storage backend: file system
Client configuration
Client version: 1.7 Operating system: Ubuntu 14.04 OS language: English
Well, you marked it correctly as a "proposal" for enhancement. :-)
I was wondering... is there some underlying system design issue due to which this was not implemented? I'm having a bit of difficulty to imagine that the current state "always delete when not synchronized" would be desired in majority of the circumstances.
I would like this to be made a priority -- the current behavior is incredibly destructive and unintuitive.
I ran into this last night: I wanted to stop syncing a folder that changes often and is backed up by git. I noticed that stopping sync would mean that the folder would be deleted. 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 shrugged, copied the folder into a different location, stopped sync and copied the folder into the proper location again. Unnecessarily complicated, but I got what I wanted -- or so I thought.
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. The safe assumption is to leave local folders as is. The user can delete anything they want to, if they choose to.
Looking at the interface I now undestand what happened. Choosing what files are synchronized doesn't actually choose what local files are synced across machines, but the opposite: what remote files are loaded onto the machine. So choosing that I don't want to sync that folder removed it locally, but the remote copy was kept. The current behavior is very unintuitive and the user interface very misleading.
I would tend to agree. Sync client should not really delete anything behind user's back via the "choose what to sync" option. It is confusing etc.
However to understand what is the desired behaviour is tricky: suppose you take the folder off the sync and then remove its content locally. 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. What about when you move files and directories around? Etc.
I think what should happen is that simply the client should forget about this directory and all its contents. 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).
What really needs to be checked is how good the reconciliation procedure in absence of local state information really is. Conflict files would be created if either local or remote file was changed. Local deletes would be reverted back to the server state. Would remote deletes be propagated locally in a correct way? What about propagating local and remote moves - would that work or not?
It might be that this case requires a special approach altogether.
And a comment on the interface @jancborchardt: with the current behaviour (deleting the files) using a checkbox to trigger this behaviour is a very counter-intuitive idea from the interface design point of view (this is even more than before applying to 2.0 interface!). It is an ACTION (and a presumably confusing one, heck) so I think there should be a PUSH BUTTON or something like that which says "Archive the folder". It would at least be more clear for the user that he triggers some archiving action which may result in file deletion. It would also be an opportunity to (optionally) pop-up the dialog box asking for confirmation and explaining that files are really going to be deleted.
@moscicki well, the files are not deleted as long as you have not clicked the button "Apply" underneath the listview in 2.0.0. So there is a proper decision to take, and there is also text explaining what happens next to the button.
That said, I think having a checkbox like [X] remove the local data next to the Apply button would solve this nicely.
The underlying idea of ownCloud client is that the server side is the master of the data, and the client just syncs parts of it. In that sense, it is fine to remove the local data. That is one way of understanding it, the other sees the client as master of the data, which syncs parts to the server to backup or share. Here, deleting of local data is unexpected.
It is challenging to combine these two ideas in one application.
@MTRichards what do you think?
@dragotin: 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. 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. So there is really no "master": every access method is as good as the other one. So if I use sync client to access my storage, then I expect my local sync folder is "my master" interface. If I use web access then my browser is "my master" interface. If I mount a webdav share into my desktop then this is my "master".
The idea of the server being a master and client just syncing part of it would be understandable if there was one-way sync and client would simply mirror the state of the server. But as we know client is the originator of new files, move operations etc. So it is really peer-to-peer relationship, not a master-slave one.
Growing number support tickets from users for whom this behaviour is very unexpected makes me think that real users also think in this way.
One problem with leaving unsynced folders on the client is that those unsynced folders live in some overall folder tree on the client that is synced. The unsynced folders are of course unselected fro sync in the "folders to sync" tree by the user. But for "ordinary" users (like mine) they forget that some folders are not being synced. They would make changes in the local copy on the client. Those changes would not appear on the server, and thus not on their other devices... Then they will make support calls saying stuff is not synching, or they will remove ownCloud client and delete the files on the client, thinking it is all synced to the server (because the ownCloud icon is green). Then there will be tears :( Not deleting the local copy of unsynced folders would have to be an option (preferably not the default). And then the issue of re-merging client-and-server when a folder is synched again has to be checked through to make sure the various possibilities of changes on both sides end up with a reasonable outcome.
I agree with @phil-davis here: You trust that everything in the »ownCloud« folder is synced, and that all changes will be made on the server as well.
Leaving unlinked dead files around locally is not good practice because it introduces a mode of having some files which are synced, and some which are not.
Leaving unlinked dead files around locally is not good practice because it introduces a mode of having some files which are synced, and some which are not.
My thoughts exactly. In general, this is a set once and forget it operation for a given desktop. A user specifically says I want that folder, and not that one. As with me, the next thing that happens is a user forgets the selective sync later, and puts files in that folder that don't sync. Then they complain about that = help desk calls.
Most users would expect the files in the folder to be synced, period. When they are unchecked, perhaps we can explain it better - "clicking the button will delete the files and folders locally, please make a copy before removing it". And then the files in ownCloud disappear.
For me (as a user of oC with 4 machines syncing), this is exactly what I want. Some machines have more space than others, and I uncheck a box to free up space on the desktop when someone shared 2 GB of data with me and I don't want it. But I always know it is on the server and one click away if I need it.
Fair point. What is going to happen when a user creates a directory which was previously taken-off sync and puts some files there?
If you choose to "unsync" FolderA (leaving it on the server but not on the client), then some time later you create "FolderA" in the client side, "FolderA" on the client gets a red "x" icon on it and the client refuses to sync it up to the server. An example of doing that is reported in https://github.com/owncloud/client/issues/3634 In that case I was also reporting that the red "x" status of some sub-folder with this issue is not propagated up to be at least a warning status on higher folders and the tool box sync icon.
@moscicki If you drop a new folder into that sync directory and it doesn't conflict with a selective sync directory, everything works as usual. If you drop a new folder with some files in it into a directory that is the same name as the server side folder that you un-selectively synced at an earlier time, you get a red x on the folder and then the folder gets removed in the next sync run.
Probably what should happen is you should get a red x on the folder and then it doesn't get deleted, ever. If you subsequently decide to sync the directory again, it should get merged and version if needed individual files.
@MTRichards: yes, I agree. This is a serious bug if my files get deleted if I put them to deselected local folder.
I just tried that with 2.0.0 and it works for me exactly as described by @phil-davis: The deselected folder, that is re-created locally, is ignored properly and not removed in a subsequent sync run. In the activity list it says Ignored because of the "choose what to sync" blacklist.
If I add the directory to sync later again, the missing files on either side are up- and downloaded.
So far I only can see the problem that in the file manager, the icon is a red cross for the ignored dir, instead of the yellow ignored icon.
@moscicki I agree too, it is a serious bug, and I decided to not use owncloud till it'll be fixed. It's absolutely unacceptable, that local files are deleted only because of the fact, that I don't want them to be synchronised. And I gues that nobody aspects that behaviour. The worst thing is, that at appears to me that this behaviour was introduced only in 2.0. So imagine that with one click I could delete accidentally thousands of important files. Please fix that and be more careful with such »features« in future.
@dragotin Sure I did, but how can I recreate a folder after it has been deleted? My scenario is the following.
- At first I added a folder A to be synchronized
- Than I decided that the subfolder A/B shouldn't, so I deselected it.
- Today I updated to client 2.0.
- And now I get the message:
Unchecked folders will be removed from your local file system and will not be synchronized to this computer anymore.
So for me it seems that if I would hit the button »Apply«, the folder A/B would be deleted. I did not test that, because I don't want that happen. So I come to the conclusion:
- Either the new client version has a dangerous function that deletes all my ignored files
- Or it gives me a message that I don't understand.
Both is bad.
I also went through the process a couple of hours ago to check it still works OK with 2.0.0 release. I created folder "Stuff" with some stuff in it and let it sync to the server. Then deselect "Stuff" from folders to sync. 5 minutes later create a "Stuff" folder in the client. It gets the red cross... and it has survived there on the client for a couple of hours without being deleted. I re-enable sync of "Stuff" - the stuff in client "Stuff" got merged with the server "Stuff".
@dragotin, I was testing with 1.8.4, and after two sync runs it disappeared. With 2.0.0 all is working as you would expect - a red x, but the folder and files are persistent as you would expect, just not synced.
@gunwald
So for me it seems that if I would hit the button »Apply«, the folder A/B would be deleted. I did not test that, because I don't want that happen.
This is the design point for this feature, and how (for example) Dropbox works. Perhaps the warning should say "please make a copy of your files" as mentioned above. Note, of course, the files remain on the server, just not on the specific desktop you are using. If, for example, you are syncing multiple devices (like me) you often want to limit what goes where and when you click you want the extra stuff to go away.
@MTRichards
This is the design point for this feature, and how (for example) Dropbox works.
In my humble opinion this is a false design decision:
- At first, it is not true, that the files are on the server first, how do they get there? It's false to think from the servers perspective: To have files on the server, you do have to do an upload from a client (Y) first, but doing that upload you may decide to exclude some folders. That does not mean you want them to be deleted at all. (If you would like them to be deleted you could do this first)
- If you now pull the files from an other client (Z) you can choose directly not to download all folders by deselecting them, so there is no need to delete ignored files neither. If you decide later not to sync some files anymore, that are already downloaded, and you uncheck them, do you really expect them to be deleted locally by unchecking them? I don't think you would.
- I don't mean that to delete unsynced files couldn't be an useful feature at all. But if you really want it, you should either add a dialogue, that asks you if you want to delete them locally, when you uncheck them (but I still think this could result in accidentally deleted files). Or you could add a button that says something like:
Delete all ignored (uncheked) files.
Conclusion: I think the way the feature is implemented now, it is dangerous and behaves absolutely unexpected
My 2 cents is that the way it works right now is exactly how all of our users are expecting it to work. In every training session I've attended we get a question from someone asking if files they no longer wish to sync are deleted or if they have to manually delete the folder they've unchecked. Every single time they've been happy that they don't have to do the extra manual step.
The content still exists on the server. Unchecking the box to me says that you don't want it on your computer. So for me, deleting the local content is completely intuitive. And from the reaction of our users it's completely intuitive for them too. And they are mostly the definition of non-IT people. If one of our users told me they wanted a copy of data but didn't want to keep it in sync I'd direct to the web interface to download the folder/s they need. Quicker to download (thanks to compression) and no fiddling with settings in the sync client.
In a corporate environment, having multiple versions of the same content (version A on the server synced with some people, version B no longer synced with one person, version C no longer synced with another, etc) is bad, bad, bad. If any changes are to be made in this area it would be a HUGE step backward not to have a branding option to enforce the existing functionality at compile time so that a user has no way of overriding. This should not be a checkbox in a tab.
I can see the benefit in a dialog box making it clear to a user that local data will be deleted but that the content is still available on the server.
@scolebrook When setting up a new folder to synchronize, if you deselect a subfolder (that exists locally as well) it gets deleted. At that point, you don't have its files on the server.
@dragotin: should we trigger someone to create a smashbox test case for this? just to make sure we don't lose files incidently (see @MTRichards test of behaviour between 1.8.4 and 2.0). I would consider 1.8.4 is a bug.
@scolebrook: OK, I understand your point. I think the main criticism for this function is that it should really be called something like "Archive: delete files locally and do not sync this folder anymore" and UI should be designed such that nobody has any doubt what is going to happen and what is the intended function of this feature. If we have that then it is a matter of liking or not liking this particular function. But the problem is when there is confusion perceived as unexpected behaviour.
For me the general problem with this feature (deleting local files) is that I think it is very hard if not entirely impossible to implement it such to avoid data loss in scenarios like @cascaval describes. Another example: I am transferring many files from my NAS or from my camera to a folder -- this takes long time -- as files are slowly trickling in. What happens when I deselect this folder from sync during this operation?
@cascaval I have never even thought about pairing a server folder with a local folder that already had content in it. I'm sure that might seem like a natural approach to some people but it seems about as backwards as you can get to me.
That said, you're right. Data would be lost and a user wouldn't be notified that that was about to happen and have a chance to change things. This is not a good user experience which is why I support the idea of notifying the user about the implications of their actions.
@moscicki For a paying enterprise customer, it's not about liking or disliking a feature. It's about losing a very important piece of required functionality in a product you've paid a significant sum of money for. This functionality is a feature, not a bug. The simple intuitiveness of it, that so many non-tech people expect an unchecked folder to be deleted locally, shows this to be the case. I'm not saying we shouldn't provide the ability for a user to change this behavior via a checkbox (so long as branding options exist to hide this) or that we don't need adequate warnings of what is about to happen to local data. I am saying that a product that is deployed to sync content should have it's primary purpose to sync content and any thing that is put in place for edge cases away from that primary purpose should be optional, not mandatory.
As to your example, why would you copy files from a camera to a folder within your ownCloud folder if you didn't want them synced with ownCloud? This is the heart of much of this discussion. Why is content in an ownCloud synced folder if the intent isn't to sync it with ownCloud. I can't find a single common sense reason for this.
You want to have a local unsynced copy of something, download it via the browser, store it outside our ownCloud folder. Download it with the sync client, pause, move it, deselect it, resume. You want to transfer content from a camera or NAS to your local hard drive but don't want to sync it? Don't put it in your sync folder. I've had more than one user complain about using words like "application" and "interface" in documentation because they are too technical. None of them have found a problem grasping the concept that if you want content to sync, put it in the sync folder. If you don't, don't.
@scolebrook My main problem with this... ehm... "feature" is that it's performed without a big strong warning. I think that any action that silently results in a data loss is a bug.
No offence but it seems to me like you are thinking only about your own agenda and sort of dismiss any use-case that doesn't match yours.
@scolebrook: you see, the main point is that a user should not shoot themselves in a foot in a way that cannot be recovered by IT which manage the service. The probability that they shoot themselves in the foot is proportional to the number of users you have in your system and at some point you can be certain that someone will lose the data in a way you cannot help them in any way. It's not about me transferring the data from my camera to my sync folder. It's about users who are confused with unclear features prone to inadvertent error as @cascaval says: without big strong warning. The tool should be designed in such a way that makes it hard if not impossible. As for the expectations of the users: I think extrapolating from your sample to the entire world is simplistic. Not all users in the world deal only with office files and have the mindset you describe. Maybe many of your office users feel this natural but I can tell you than 99% of my engineer users are truly confused and plain hate this feature. Since I have a varied mix of users this is not an easy problem to solve. But as a paying customer I also require that expectations of my users are taken into account. Does it bring us any further in this conversation?