Unchecking synchronized subfolder without local delete #2502
Comments
|
I think that it is not in the roadmap, @dragotin isn't it? |
|
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. |
|
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. |
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. |
|
@moscicki looking into it, that is a good question. |
|
@moscicki 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. |
|
@gunwald did you read my last comment? |
|
@dragotin Sure I did, but how can I recreate a folder after it has been deleted? My scenario is the following.
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:
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. |
|
@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. |
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. |
In my humble opinion this is a false design decision:
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? |
|
An "ordinary" user who unsynched a folder and was then surprised that the files in the folder are not synching? Extraordinary!
Bob S
On Nov 29, 2022, at 01:19 , Klaas Freitag ***@***.******@***.***>> wrote:
All that seemed too confusing for ordinary users
|
|
Yes, believe it or not. Because between the two events "unsynching" and being surprised can be quite some time. I am sorry. |
|
Cloud first or not, that does not mandate local deletes. Scenario: In a large company, I am occasionally working with data from another team. E.g. Marketing team has "everything" in the cloud, and for an annual presentation, I'd like to fetch a presentation template from their tree. Basically I am a read-only user here, and daily updates are not wanted. (A very user friendly - future - desktop client might track when a file is "used", check with the server and tell me about available updates.) |
|
It's mind-boggling that users have been explaining this desire to devs since 2014 (!!!), and the answer is still "what would be your use case for that"? For all that is sacred, users demand an optional feature that would need to be specifically opted into in any case, and the decision still is that "it would confuse users"? No, it wouldn't confuse users to begin with, and if so, the sync icon overlay would be removed from the non-synced files/folders, so there would be immediate visual cue. Also, this possibility could be hidden behind an off-by-default option in the settings, and when the user enables it, there could be an unmistakable dialog warning about the "danger". This could be implemented in a non-confusing way trivially, and the excuse is the same dumb argument in the last 8 years 🤦♂️ |
|
If you argue this is a dumb argument, well... what can I say? If you even more think that it can be implemented trivially, I'd say: How about sending a patch? I hear your arguments, but around twelve years of sync client development have taught me one thing for sure: Be clear in the concepts, and do not focus on the expert users. Adding more "hidden options" does not help. Really not. People will confuse that. I hope you can accept that. |
|
For what it's worth, I failed to understand in the last 7 years (since I've occasionally taken part of this conversation) how having this option would definitely confuse users, but the exclusion patterns (which are also user configurable, and it's really easy to say exclude all the .docx files) don't. So yes, I think this is a largely unfounded argument. And of course I wouldn't even consider putting any more effort into this (other than these comments) as long as there's so fierce principles-based resistance from the core devs despite so many people requesting it. Would be an absolute waste of time on a rejected PR. If it would be like "we generally agree, just won't do the work guys", then, maybe, I'd consider contributing. |
|
The "Cloud first" sentiment creates a contradiction at the center of the debate as it overlooks everything in the cloud originated elsewhere. The cloud is ever a relay or sync engine, forwarding changes generated elsewhere. That's why 99 of 100 users are surprised to learn, (such as when bugs appear such as a corrupted or out of date cloud database, data is 'not synced as it was supposed to be') we can't believe our eyes when turning off syncing deletes what might be considered possibly more authoritative than what's in the server. Particularly when the server appears to have 'gone away' for unclear reasons.. the client may well decide syncing 'automatically' when it comes back (with who knows what database or file content hours or days or weeks later) isn't something they'd like to trust about, but would like a 'ask me on each difference before changing local content'. Why not by default when turning off syncing on a folder removing only tech/admin files/flags owncloud created. Perhaps with an option to delete the local dir tree. Should the client at some later time 're-turn on' sync with that folder, as owncloud can note the existence of the folder on the server, any client files that conflict in content with server files generate the usual conflict resolution process with that user. Which, it seems to me, is what the server does now anyhow when the client already had a folder with content in it, then later asked that it be synced to a folder with a name already managed by the server. Besides this meeting the default expectation of most users, it manages the case when there is corruption in the cloud database with unresolvable and laconic 'checksums don't match' errors when the old database is restored but some files on the server have different checksums. So, the user reasonably thinks 'well I'll just unsync, resync and answer questions about differences per file if they arise'. The user unsyncs, wipes out their authoritative files, remains beset with error messages that the system provides no way to resolve, then finds their way to this thread, thinking to themselves 'you know, I'm going to not use this, because what other major category mistake is built into this I can't guess about until it costs me more than it is worth'? |
|
Unfortunately, the devs have decided for better or worse that this is how it is going to be. They have presented their case many times, not without merit. But the bottom line is that this is a deal breaker for most people, who upon discovering this "feature" decide against deploying it. Imagine going to your boss, and trying to sell him on this. "What happens if we decide to switch to another cloud based solution?" "Well sir, all of our data will be deleted."
Yeah. No.
Bob S
On Jan 19, 2023, at 08:43 , Harry G. Coin ***@***.******@***.***>> wrote:
The "Cloud first" sentiment creates a contradiction at the center of the debate as it overlooks everything in the cloud originated elsewhere. The cloud is ever a relay or sync engine, forwarding changes generated elsewhere. That's why 99 of 100 users are surprised to learn, (such as when bugs appear such as a corrupted or out of date cloud database, data is 'not synced as it was supposed to be') we can't believe our eyes when turning off syncing deletes what might be considered possibly more authoritative than what's in the server.
Why not by default when turning off syncing on a folder removing only tech/admin files/flags owncloud created. Perhaps with an option to delete the local dir tree. Should the client at some later time 're-turn on' sync with that folder, as owncloud can note the existence of the folder on the server, any client files that conflict in content with server files generate the usual conflict resolution process with that user. Which, it seems to me, is what the server does now anyhow when the client already had a folder with content in it, then later asked that it be synced to a folder with a name already managed by the server.
Besides this meeting the default expectation of most users, it manages the case when there is corruption in the cloud database with unresolvable and laconic 'checksums don't match' errors when the old database is restored but some files on the server have different checksums. So, the user reasonably thinks 'well I'll just unsync, resync and answer questions about differences per file if they arise'. The user unsyncs, wipes out their authoritative files, remains beset with error messages that the system provides no way to resolve, then finds their way to this thread, thinking to themselves 'you know, I'm going do not use this, because what other major category mistake is built into this I can't guess about until it costs me more than it is worth'?
—
Reply to this email directly, view it on GitHub<#2502 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADSJUNFLIAYAJJFJO4Q2ETTWTFVLPANCNFSM4AXRT4JA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Bob, the merit the devs mention is of a technical nature that overlooks owncloud itself advertises it is not a backup solution, is itself subject to catastrophe such as an old restored owncloud db having different checksums that the files in the tree. The merit they rely upon is an active choice to overlook realities that don't lead to where they prefer to go. I argue there is a contradiction at the heart of the argument to 'delete first' because 'cloud first' overlooks where the data began in the first place. To be accepted, owncloud must put clients in the 'driver's seat' and give each the burden of deciding upon 'resync' whether to accept local or cloud versions as authoritative. In effect, deciding to 'delete first' takes away the client's ability to choose upon resync. It also assumes that the cloud is 'always right' -- a direct contradiction to the owncloud folks arguing that it's not a backup solution. Either claim to be a backup solution and own it, or give the users the burden they actually already have and abandon the delete first policy. |
|
Agreed. That's why I called it "unfortunate."
Bob S
On Jan 19, 2023, at 09:27 , Harry G. Coin ***@***.******@***.***>> wrote:
Bob, the merit the devs mention is of a technical nature that overlooks owncloud itself advertises it is not a backup solution, is itself subject to catastrophe such as an old restored owncloud db having different checksums that the files in the tree. The merit they rely upon is an active choice to overlook realities that don't lead to where they prefer to go. I argue there is a contradiction at the heart of the argument to 'delete first' because 'cloud first' overlooks where the data began in the first place. To be accepted, owncloud must put clients in the 'driver's seat' and give each the burden of deciding upon 'resync' whether to accept local or cloud versions as authoritative. In effect, deciding to 'delete first' takes away the client's ability to choose upon resync. It also assumes that the cloud is 'always right' -- a direct contradiction to the owncloud folks arguing that it's not a backup solution. Either claim to be a backup solution and own it, or give the users the burden they actually already have and abandon the delete first policy.
—
Reply to this email directly, view it on GitHub<#2502 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADSJUNDTDFCDCC4DAO3F3N3WTF2O7ANCNFSM4AXRT4JA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
There are two aspects I did mention before which seem overlooked: |
|
I would like to be asked, if I want to delete the local files or leave am intact, when unchecking a folder. When I re-check the checkbox, I would like to be asked if the server version of all files should be used, the local version of all files should be uploaded to the server or if I want decide on a file by file basis. Thanks a lot. ps.: nothing should happen automatically, but it would be good, if the server admin could restrict this option for users/groups, so they can still can wipe data from clients if the have to. |
@derWalter, this is literally what we've been asking for for 8 years now, dozens of people wrote in support of this, we proposed several potential implementations, and the devs always dismiss it all citing quite obscure principle-based arguments. They think that this would both be "confusing" to users, and would violate the principle of "server is master" (whatever that would mean in practice). |
|
@mortee @derWalter I have exactly the same issue and would fully appreciate an option to leave the local files intact. |
|
+1000 from virtually everyone
…Sent from my iPhone
On May 20, 2023, at 06:18, Olliver Schinagl ***@***.***> wrote:
Just dropping some pennies here,
I was flabbergasted that unchecking the checkbox wanted to remove local files. I could cancel the action just in time, becuase otherwise I would have lost years worth of work, just because I didn't want to sync 1 folder of a whole tree. That's just insane and horrible UX. To accomplish the same, I have to fumble with exclude patterns, and just hope I get it right. Again horrible UX.
I think what's generally missing, is a treeview, just like the select, an exclude. This would help a lot already but would lead to a confusing UI, in the main tree view, we now select something, that we then unselect in the exclude tree.
I recon the confusion comes from the fact that a checkbox is used, where something that has multiple-choices is needed. From a clicky point of view, I get the desire to have a checkbox, though not sure how easy it is (and how confusing that would be) to have a checkbox that can do multiple things. A drop-down would be far more accurate in that sense.
[sync]
[ignore] (do not sync, but do not delete)
[unsync] (delete local files)
is in short what seems to be what is missing. Ignoring a folder is what everybody here is after. If that means, internally it just adds something to the exclude list, that's an implementation detail.
Having said that, having a confirmation 'going to delete ' would still give the user a moment of 'uhm, that's not what I thought this would do'. Deletion is a destructive operation, potentially loosing years/lots of money' worth of data, Even though the sentiment is 'but the user unclicked it' shouldn't mean 'ok lets just throw it all way without confirmation'. Heck even a file browser asks confirmation.
—
Reply to this email directly, view it on GitHub<#2502 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADSJUNG73EUZXERL6LYFFCTXHDACNANCNFSM4AXRT4JA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
And another +1,000,000 |
|
+1 for the solution that @derWalter mentioned! |
|
+1 @derWalter |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@hcoin @q2apro @slylabs13 this is the ownCloud repo, not NC |
|
So Owncloud has the same problem. You should also fix it. I posted the issue at https://help.nextcloud.com/t/unchecking-synchronized-subfolder-without-local-delete/172874 and at Nextcloud's issue tracker: nextcloud/desktop#6169 Maybe Nextcloud is finally fixing it. |
|
Chronosync seems to have solved the puzzle nicely.
…Sent from my iPhone
On Oct 24, 2023, at 23:30, q2apro ***@***.***> wrote:
So Owncloud has the same problem. You should also fix it.
I posted the issue at https://help.nextcloud.com/t/unchecking-synchronized-subfolder-without-local-delete/172874 - Maybe Nextcloud is finally fixing it.
—
Reply to this email directly, view it on GitHub<#2502 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADSJUNB3OSVXCRNSK6RCBMLYBCPX7AVCNFSM4AXRT4JKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZXHA2TIMJZGQ4A>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@slylabs13 can you explain how chronosync does it? |
|
In their settings you can choose to sync left to right, right to left or merge both sides. Also, you can choose what attributes to use to detect a conflict. Finally, if a conflict cannot be resolved, such as. Right to left sync with a newer file on the left, the old file is saved in a conflict folder inside the folder with the conflict. You can also opt to keep a certain number of versions.
…Sent from my iPhone
On Nov 5, 2023, at 03:29, Jürgen Weigert ***@***.***> wrote:
@slylabs13<https://github.com/slylabs13> can you explain how chronosync does it?
—
Reply to this email directly, view it on GitHub<#2502 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADSJUNFSJABP7M6LAIBT6UDYC52AFAVCNFSM4AXRT4JKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZZGM3TCMBQGA4Q>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I guess the way how Freefilesync (https://freefilesync.org/) handles synchronizations would also be a candidate to look to. |
|
Ridiculous that it can't just support a simple ignore list of folders / files not to sync 🤷🏼 This is the 4th sync tool I've used, it's such a simple thing but they all either force you to delete or sync 100% of stuff Impossible to use for developers with giant node_modules directories and such |
and others
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
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
The text was updated successfully, but these errors were encountered: