client 🚀 - Unchecking synchronized subfolder without local delete

I think that it is not in the roadmap, @dragotin isn't it?

luciamaestro on 17 Nov 2014

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.

ts-mk on 17 Nov 2014

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.

jaranta on 23 Aug 2015

👍11

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.

jaranta on 23 Aug 2015

👍2

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.

moscicki on 23 Aug 2015

👍3

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 on 23 Aug 2015

👍1

@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 on 23 Aug 2015

👎1

@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.

moscicki on 23 Aug 2015

👍2

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.

phil-davis on 23 Aug 2015

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.

jancborchardt on 24 Aug 2015

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.

MTRichards on 24 Aug 2015

Fair point. What is going to happen when a user creates a directory which was previously taken-off sync and puts some files there?

moscicki on 24 Aug 2015

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.

phil-davis on 24 Aug 2015

@moscicki looking into it, that is a good question.

MTRichards on 25 Aug 2015

@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 on 25 Aug 2015

@MTRichards: yes, I agree. This is a serious bug if my files get deleted if I put them to deselected local folder.

moscicki on 26 Aug 2015

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.

dragotin on 26 Aug 2015

@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.

gunwald on 26 Aug 2015

@gunwald did you read my last comment?

dragotin on 26 Aug 2015

@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.

gunwald on 26 Aug 2015

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".

phil-davis on 26 Aug 2015

@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.

MTRichards on 26 Aug 2015

@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 on 26 Aug 2015

@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

gunwald on 26 Aug 2015

👍2

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 on 26 Aug 2015

@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.

ts-mk on 26 Aug 2015

@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?

moscicki on 26 Aug 2015

@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 on 26 Aug 2015

@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.

ts-mk on 26 Aug 2015

@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?

moscicki on 26 Aug 2015

@cascaval I'm thinking about a wide array of use cases that have been presented to me by several hundred people, none of which match my own use case. That of course doesn't include every plausible use case. But there are several examples here where I fail to see logic. You gave an excellent one though where someone is pairing a folder that already has content locally but not on the server. I said that seems a totally backward way of doing things to me but it obviously wouldn't to other people which is why I said that you were completely right in that example and as things stand, that user would have a bad experience.

I agree that the lack of a warning is a bug. Absolutely. Any scenario where data is to be deleted due to a user action, whether they are expecting that data to be deleted or not, should have a warning. If you empty the trash on your computer you are expecting the data to be deleted. That's specifically what you are wanting to happen. That's the only reason to empty the trash. Yet there's still a warning unless you disable it.

However I strongly disagree that the feature itself is a bug for the reasons I've stated above. There are thousands of folders on the average hard drive. Why must content that isn't supposed to be synced to the server live in the one folder out of those many thousands that is designated to be kept in sync? Why can't one of those other folders be used, or even a fresh shiny new one? I've not seen any attempt at explaining that yet. None of the use cases address that but that's what most of this discussion seems to boil down to.

Perhaps selective sync doesn't need change at all. Perhaps the process for add folders needs to be changed to have a list of checkboxes for server side folders you want to sync. You check a box and get prompted to nominate a local folder to pair with instead of the current wizard.

scolebrook on 26 Aug 2015

@moscicki As stated multiple times I agree with the need for a warning. I've never said anything to the contrary. I am only stating that the behavior of a sync client should have something to do with keeping two copies of the same content in sync, not providing means to keep them out of sync. One of those is intuitive.

Many of our users are not office workers. We have a wide range or people including photographers and videographers who are using ownCloud to injest many GB of data from around the world into our content management system, typically file sizes are up to 100GB. We have also have about 150 IT support staff, engineers and developers using ownCloud who have not complained once about this feature. My sample is far more diverse than you think. We've conducted surveys among our user base to try and accurately gather feedback about how they use ownCloud and where they see problems in their workflows. We do this to find feature request (although we get new ones almost daily) and to find frustrations and fix them before there are problems. Much of this has to do with integrating ownCloud into existing workflows and processes or interaction with other software in our stack. Not once has anyone had anything negative to say about selective sync. As I've stated earlier, the only feedback I've received on this particular aspect has been positive.

I haven't seen use cases that make sense for storing non-synced content in a location specifically designated for syncing, I've still proposed branding options so that both forms of functionality can be accounted for but giving admins the choice of how they want to their installation to function. It doesn't matter to me which way ownCloud go with their version so long as I can control how the client behaves for us. I've even suggested changes to add folders to bring the intuitiveness of the list of checkboxes to it for pairing a local folder to a server side folder. What I do not want is a loss of functionality and to me, apart from adding warnings, that is what is being proposed.

scolebrook on 26 Aug 2015

Actually, my previous statement about no negative feedback about selective sync isn't quite true. We've had feedback about automatic sync of large folders which is fixed in 2.0. Just want to be clear on that.

scolebrook on 26 Aug 2015

@scolebrook: makes sense!

moscicki on 26 Aug 2015

Why must content that isn't supposed to be synced to the server live in the one folder out of those many thousands that is designated to be kept in sync?

@scolebrook Sorry, I think you are missing the point: You can add every folder of the thousands you have to be synced with Owncloud, it does not has to be inside the one an only owncloud folder. And that's a very important feature for me Owncloud.
And as I said before: In my opinion its wrong to think only form the point of view of the server, where already all files are stored and now the clients choose what they want to have an what not. But how do you get those files to the server?

In my use case (and I think its the same for most private users) I use Owncloud to sync my private data with a server and my other devices. In my given file structure I add the folders I want to sync to owncloud an deselect those subfolders I don't want to be synced. It never even came to my mind that ignoring files could mean deleting them and I don't know no other sync, versioning or filesharing program that acts like that.

If you add an ignore pattern to git, would that mean git will delete the ignored file? No!
If you ignore a file in syncthing would it delete it? No!

If you think, there should be a way to delete all ignored files (in my opinion a feature that could come in handy but isn't important) than it could be added. But to have a button that kind of suggest to you to delete all ignored files an not even asks you if you really want that, is a bug.

So, I think, the best way to add that feature would be a dialogue that uncheking a folder asks you:
_Would you like to delete this folder locally?_
If you say ›yes‹ they should be moved to the trashbin.

gunwald on 26 Aug 2015

@gunwald I don't see selective sync as equal to an ignore list. It's an opt in system. The ignore list in ownCloud functions just like the ignore list in git. When you check a box in ownCloud you're opting in to syncing that folder. When you uncheck it you are saying that you don't want to sync it anymore. And you should be given a warning about what happens next.

As to the what happens next, I agree that the content should be moved to the trash rather than deleted immediately. That gives the user another opportunity for self recovery from a wrong decision. For those who want to have the client add that folder to the ignore list for them rather than delete it, that could be added as an option so long as it can be disabled via branding for reasons previously stated. Re-checking a box in selective sync would need to check if that folder currently exists locally. If it is, the user needs to be given the option to cancel, merge, replace from server or replace from local. It would also need to check if that folder is in the ignore list from a previous deselection and remove that item in the list.

scolebrook on 26 Aug 2015

If you say ›yes‹ they should be moved to the trashbin.

Nice idea but the files could be too large for the trashbin. Couldn't we just give a notice that the un-selected folder needs to be removed from the owncloud-folder. Do you want to keep a local copy at a different location?

tflidd on 26 Aug 2015

Maybe I am using this in a way that it was not intended to, but I use owncloud more of a back up and share service between machines. So I actually never use a "owncloud-folder" (I actually hate that a new install assumes that). So what I do for example is after install on some machines I might say sync ~/Documents so this is fine, and then one machine maybe no longer has enough space for all the contents in ~/Documents so I want to stop syncing. In this case I still want the local copies I am just choosing to no longer "back them up".

My point here is that as you consider test cases and use cases please consider that some users are syncing normal "system" folders and not a subset of an "owncloud-folder"

I like the suggestion several days ago from @dragotin with a checkbox "Remove Local Data" it could even default to on.

sprocket888 on 28 Aug 2015

+1 for the original request

mortee on 24 Nov 2015

confusion

as it seems, there is a confusion regarding ignoring and not-syncing/blacklisting. as i understand the comments in this thread it seems that the

ignore-list (i.e. csync's sync-exclude.lst) completely ignores the files (the software is not "aware" about them in the first place, while the
blacklist is excluding files - which the client software is aware of (and thus displaying them in the UI) - from storing locally.

based on this two different concepts, the files are handled in different ways:

ignored files and folders are
- _deleted_ if the "allow deletion" (]) option is set with the ignore pattern,
- _preserved_ otherwise.
blacklisted folders get _deleted_ locally, as they seem to be "unwanted".

while everyone seems to agree of the behaviour of the client regarding the _ignored_ files, this seem not to be the case for the _blacklisted_ ones:

the first group (dev/designers?) seem to agree with the behaviour, as it seem to be intuitive.
at least some users seem to not agree, as the behaviour seems counter-intuitive.

discussion

i personally strongly vote against the distinction in the processing that is currently done. e.g. unison threats ignored files equally to oC, while the Path selection is a real opt-in functionality: only paths listed there, will be synced - the rest ignored. (oC differs here in that new folders are considered to be automatically opted-in. so it is not a plain opt-in (as @scolebrook argued). _unison_ also allows to sync everything or certain subdirectories to always sync in favour of one direction or for the newer or older (prefer or preferpartial). Synchronize Ultimate or FolderSync both support one-way sync of folders, ignoring local changes or deletes.

the argumentation that oC "owns" the files (see @MTRichards comment in #4278) made some sense as long as it was possible to only sync one folder (%HOME%/ownCoud by default). but since now multiple folders can be synchronised, it does of course change the fact, that only "clouded" and "shared" files are synced, but that the client is also used for replicating directories between devices. in this regard, i do agree with @gunwald (see here) that files first need to go to the server. so the idea, that they are coming from and thus owned by the server is somehow understandable, but eventually wrong. :-)

nevertheless, i do also appreciate the position made by @scolebrook in on the same issue: his line of argumentation is, that

people are happy, that content gets deleted upon un-checking (here)
in enterprise environments "it's about losing a very important piece of required functionality" (here)

probably there will be no consent on which of the two behaviours is to be preferred. thus, what solution can unite the two? - how about the following proposition:

what can be done?

the functionality is in general kept as it is, with some modifications.

when adding a new folder sync, on the the page where subfolders can be unselected:

not only folders will be listed, but also files, once the parent folder is opened (deferred loading), as long as they are not in the default ignore-list
local files and folders are shown as well (mangled with the remote items where the path match), as long as they are not in the default ignore-list
an option show ignored files and folders is added to the dialog,
- unselected by default, but
- when selected, ignored files (that are found on either side) will be shown in the list of all opened levels with
  - text grayed and
  - checkbox unselected.
- when again unselected, the ignored items get hidden/removed from the list
the current column Size will be renamed to e.g. Remote Size
if any existing local item is found (point 1) a new column is added, showing the Local Size
- local file scan should probably be deferred until the folder is opened in order to not consume too much time. the Local Size field could display double click and run a file-scan on that particular subdirectory and it's descendants, when the user double clicks on that field. otherwise the size will be displayed, once all subfolders have been opened by the user.
all folders and files are selected by default and will be merged (conflict handling?)
when the user un-selects an item, a drop-down with the following option is opened, if local items do exist at the given path (or below):
- delete all local files recursively, including ignored ones
  - item will be added to the blacklist
- delete all local files recursively, respecting the ignored list
  - item will be added to the blacklist
- add item to the ignore list using
  - exact path
  - folder or file name
  - file extension (if a file)
  - the options here could be extended, eg. by this extension from this path and below, etc. but that would require a more sophisticated exclusion functionality than csync is currently offering.
when the user re-selects an item, that is not ignored, it will simply be removed from the blacklist and the pending delete action cancelled.
when the user selects an item, that was ignored, a drop-down similar to the one above would be opened, also showing all rules that makes the file _ignored_ on the first level. on the second level an (mutually exclusive) checkable options:
- except current item from this rule
- delete rule
when a user un-selects an item, that has previously been ignored, the same drop-down opens so the user can either change his choice by selecting an other option or undo it by removing every selection.
all changes (deletion, blacklist and ignore list additions) would only take effect once the user confirms adding the sync folders.
last but not least, a virtual folder for [new folders] should be added at the bottom of the list of every directory, allowing the same functionality for later created subfolders (e.g blacklisting {parent folder}/*), still honouring the user set confirmation setting for large new folders.

this new functionality (showing ignored items, put items on blacklist or ignore list, remove items from either list) should also be available in the main window, once the folder sync definition is saved.

it might be necessary that the ignore-pattern-engine of the csync module needs to be extended by regex. i will propose this on a separate issue with a possible suggestion for implementation.

maybe with such an implementation, all user needs could be satisfied.

martin-rueegg on 15 Dec 2015

I there any news on this? Since this behaviour was introduced I can't use the feature to uncheck subfolders any more. An I agree with gunwald, that this is a bad design decision as it comes totally unaccepted. I do not know any other peace of software, where an action where you uncheck files means to delete them.
Why don't you just pop up a dialogue, that after unchecking asks the user, whether or not he wants the unchecked folder to be deleted? That would be much more intuitive an a solution, that woks for private users and companies.

Frank-Zappa on 29 Feb 2016

I think this is not a good design decision. I try to explain how I used to use Ownclowd and how, IMO, most private users do:

You set up an (empty) instance of the Owncloud server.
You connect device A to it, say a desktop Computer.
You select some folders from that device you want to upload and sync with your Owncloud server. You deselect some subfolders of that folders you don't want to be uploaded, for various reasons.
You may connect a second device B to your Onwlcoud instance, say a notebook with a small HD.
You choose some of the folders you uploaded in step 3. to be downloaded an syncted to your notebook.

What would you expect:

In step 3. you would expect, that the deselected subfolder is not uploaded to your owncloud instance.
In step 4 you would expect the subfolder not to be on the server, as you deselected it in step 3.

What happens instead:

In step 3. Owncloud refuses to exclude the subfolders as long as you not agree to delete them entierly form device A.
These subfolders are now synced to device B, as you could not deselect the in step 3.
Now you might deselect them on device B instead. Owncloud asks you, to agree to delete those files locally on device B to be able to deselect them.
This does not make sense as those files aren’t downloades at this point.

What is the point:

Why would you agree, to delete the subfolders in step 3? Why would deselect them mean you want to delete them? If I don't want to keep them, why would I use Owncloud to delete them. Wouldn't I use usualy a file manager for this kind of action?

naomiyoshida on 13 Mar 2016

What is the point:

Why would you agree, to delete the subfolders in step 3? Why would deselect them mean you want to delete them? If I don't want to keep them, why would I use Owncloud to delete them. Wouldn't I use usualy a file manager for this kind of action?

@naomiyoshida, I guess there is agreement on the fact, that the situation is currently not satisfying, but different user groups - or dev groups - have different approaches (which I have laid out above and here:

Now, the workflow you laid out, is not shown entirely correct, as step 3 in your list is not possible in that very procedure:

You set up an (empty) instance of the Owncloud server.

You connect device A to it, say a desktop Computer.

You select some folders from that device you want to upload and sync with your Owncloud server. You deselect some subfolders of that folders you don't want to be uploaded, for various reasons.

If your server (or at least your account on that server) is new, there _is_ no possibility to deselect any folders from the sync _as only _remote* folders are listed in the dialog*. To achieve your procedure, you would have to split that step into

add some folders (either during setup of the account, or later)
wait until they are synchronised to the server
_then_ deselect them.

I point this out because you can only deselect them, once they are synchronised and _authority has shifted to the server_ (see below) at this point of time.

The workflow oC is designed for is as follows:

set up a server (empty)
install a client (master)
1. on that client, create a new empty folder at the edge of the existing file structure,
  e.g. $HOME/ownCloud (similar to dropbox's functionality, which is seen as kind of reference in that sense)
2. add (copy) some files to that new "owncloud container".
  - thus those clients will be synced from now on.
  - the _authority_ of those files lies now at the oC server
repeat step 2. on other clients (slaves)
- now the files of the master client get synchronised to the slaves.
if on any device (be it master or slave) you
- add (copy) or remove a file or folder, this change gets replicated to the other devices (and you would do that outside the oC client, eg. in File Explorer.
- untick a folder in the cC client instead, it is considered to be locally _excluded_ from the sync-set and thus deleted (locally)

This workflow design does not fit properly (or at all) with the workflow you laid out and which I think is a valid workflow too, but differs from the above that you would want to keep the _authority_ of the files on your master client.

The argumentation from the devs is, as far as I understood, that you would have to use the (somewhat hidden) feature of _ignoring_ files (as opposed to _excluding_). You can change the ignored files list in the oC client GUI in General / Advanced / Edit Ignored Files.

Of course, this solution is a very clumsy (as the feature is hidden its use complicated) and even not fully functional as the Ignored File list is on global level, and not per-account or per-folder (and you might want to ignore the path /My Pictures in owe account or folder, but not in an other.

Unfortunately, this issue seems not to be a high topic on oC's todo list, as it is still only an "enhancement - proposed" at the time of writing. This is a bit astonishing as it seems to affect a large user base.

@MTRichards and @guruz, do you have any knowledge about the internal status of this discussion? Are the dev's aware about this?

I think there's definitely need for improvement here (see my suggestions in this comment).

martin-rueegg on 13 Mar 2016

Hi all,
I googled for this topic, and do you know why ? ... Because, of course, I accidentally erased my local files after unchecking a folder from the synch selection. I could partially recover the copy on the server but I LOST the local files that HAD NOT BEEN SYNCHED ! And additionnally, these where personal files.
Previously, martin-rueegg, has writen similar scenary, and other too probabnly.
While reading further I understand that the best design choice is not straightforward.
I would just recommend to add a warning in case of files erasing (that could save life of many...). And about the "Ignore files" edition, it does not look intuitive if I want to simply ignore synching a folder (no folders cascading check boxes).
Anyway... thank you for the great work... I am still a fan !!

pierv on 14 Jul 2016

I am a user, and here is my use case:

I have a directory containing audio files (ogg and mp3) in my folder "Music". There is a sub folder "Music/audiobooks". I want to share/upload all files in directory "Music", except "Music/audiobooks".

If I uncheck "Music/audiobooks" in the GUI, then my local files get deleted.

How can I skip "Music/audiobooks"?

I ask myself why this checkbox exists in the GUI at all. If I want this sub directory to be deleted, then I could delete it in nautilus or the shell.

AFAIK there is some magic hidden feature where I could blacklist "audibooks" (sync-exclude.lst). I guess I could use it. I have big trouble to explain this to my wife and my mother .... I get it, but they don't.

The current tree of checkboxes is confusing. Please ask new comers what they think this checkbox will do. I guess most human beings guess that the checkbox means "ignore this directory" (like sync-exclude.lst).

Thank you very much for making setting this for milestone 2.3.0!

guettli on 11 Aug 2016

👍2

You have to think the other way round. You have a music folder on your
server but you only want to sync jazz music, so you can deselect all
other folders. The server is considered to be the master holding all
possible sync files.

On 2016-08-11 7:27, Thomas Güttler wrote:

I am a user, and here is my use case:

I have a directory containing audio files (ogg and mp3) in my folder
"Music". There is a sub folder "Music/audiobooks". I want to
share/upload all files in directory "Music", except
"Music/audiobooks".

If I uncheck "Music/audiobooks" in the GUI, then my local files get
deleted.

How can I skip "Music/audiobooks"?

I ask myself why this checkbox exists in the GUI at all. If I want
this sub directory to be deleted, then I could delete it in nautilus
or the shell.

AFAIK there is some magic hidden feature where I could blacklist
"audibooks" (sync-exclude.lst). I guess I could use it. I have big
trouble to explain this to my wife and my mother .... I get it, but
they don't.

The current tree of checkboxes is confusing. Please ask new comers
what they think this checkbox will do. I guess most human beings guess
that the checkbox means "ignore this directory" (like
sync-exclude.lst).

Thank you very much for making setting this for milestone 2.3.0!

You are receiving this because you commented.
Reply to this email directly, view it on GitHub [1], or mute the
thread [2].

*

Links:

[1]
https://github.com/owncloud/client/issues/2502#issuecomment-239076676
[2]
https://github.com/notifications/unsubscribe-auth/AHvEYLfjYTVY8ZUuKy9LOr4d9lV3a3h4ks5qerK2gaJpZM4C8Z8S

tflidd on 11 Aug 2016

👎1

@pierv: that sounds very bad to lose local unsynced changes. it would be important to reproduce this issue. do you remember the particular time sequence that triggered this issue for you? how many file were affected? did you unselect the tick-box while your application was writing to a file did you do it while the sync was in progress.

moscicki on 11 Aug 2016

Also a user. From a software engineering perspective I get the "The server is considered to be the master holding all possible sync files." notion, but in every real life scenario a local client is going to be holding the files first and foremost. After everything has been synced up to the server and I'd like to stop syncing a particular folder with the server, it seems obvious that this should be possible without the local files being deleted.

b12f on 11 Aug 2016

Yes, the server is the master. Like a "remote" in git. And git provides ".gitignore". It would be nice to have something like this.

guettli on 11 Aug 2016

Ignore list exists already:

The overall discussion is more complex of course.

On Thu, Aug 11, 2016 at 11:41 AM, Thomas Güttler [email protected]
wrote:

Yes, the server is the master. Like a "remote" in git. And git provides
".gitignore". It would be nice to have something like this.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/owncloud/client/issues/2502#issuecomment-239115877,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAl9jTp3odIIo9E8mh-jYFv8q6f6-w1jks5qeu5MgaJpZM4C8Z8S
.

Best regards,
Kuba

moscicki on 11 Aug 2016

I can't see why developers have a hard time understanding that in _any_ use case, people very often simply want to store stuff _within_ synchronized folders which they don't want on the server.

When OC is used for collaboration, I may have private files in there. Like, in a shared project folder, I want to have a subfolder for my own playground, temp files, notes, whatever. They belong to the project, but only for me.

When I use OC for syning my own private files among devices, I very well may have a lot of stuff I only want to be present on certain devices. Like, I want to sync my home folder, but I need movies (who am I fooling - _of course_ porn) only on my desktop computer.

The reason to exclude files also may vary from private things to only locally needed files to stuff that are simply too big and I don't want to exhaust my storage quota and burn my bandwidth by syncing those to the server.

And NO, the exclude pattern list is NOT suitable for this. First, it's totally inconvenient to use (as already noted just today), they don't let me exclude _specific_ files/folders (as opposed to just patterns), and also they apply to all synced locations.

Regardless of all the nice theoretical considerations and bold principles like "the server is the master holding all possible sync files", users keep asking for checkboxes for only locally kept files within synced folders for _years_ now - implement this already please.

mortee on 11 Aug 2016

Ah, and I can't stress enough what also has been mentioned multiple times: deleting data as a result of unchecking some checkboxes (_especially_ without unmistakable and unavoidable warnings/confirmation) is _both_ unintuitive and recklessly dangerous. Which directly conflicts with the purpose of a system that is at least in part used for data safety/backup.

mortee on 11 Aug 2016

Well, I must say I agree @mortee. The question is how to design it in a way
that is both intuitive and not confusing with existing features.

On Thu, Aug 11, 2016 at 1:27 PM, mortee [email protected] wrote:

Ah, and I can't stress enough what also has been mentioned multiple times:
deleting data as a result of unchecking some checkboxes (_especially_
without unmistakable and unavoidable warnings/confirmation) is _both_
unintuitive and recklessly dangerous. Which directly conflicts with the
purpose of a system that is at least in part used for data safety/backup.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/owncloud/client/issues/2502#issuecomment-239135339,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAl9jaxnjtkmc0CiUooPUffd8AfJcz31ks5qewcYgaJpZM4C8Z8S
.

Best regards,
Kuba

moscicki on 11 Aug 2016

I guess it shouldn't be so freaking hard. For example, instead of checkboxes, each folder (or maybe even individual files) should have three radio buttons:

synched
not synched locally (the unchecked state in current client's operation)
keep only locally

This even would make it more obvious for the user that after applying changes, what would actually happen to the affected data.

Going into details: yes, the column headers for the radio buttons should be at least this verbose (put it vertically/tilted if it fits better), and the entire columns should have popup tool tips explaining what it would really do.

mortee on 11 Aug 2016

👍5

I guess it shouldn't be so freaking hard. For example, instead of checkboxes, each folder (or maybe even individual files) should have three radio buttons:

synched

not synched locally (the unchecked state in current client's operation)

keep only locally

I totally agree with that.
As a comment/suggestion for the dev team, when the user select a folder into "keep only locally" mode, you could simply add it into the ignore file automatically.

Ps I edited my comment in case I was unlcear.

steph-ben on 26 Dec 2016

Thanks for the extremely valuable input. See the end of my first comment from aug 11.

mortee on 26 Dec 2016

This would be a great enhancement!

ggeorgg on 25 Apr 2017

May as well toss my two cents in here. I was appaled that local files are deleted when a subfolder is unchecked. +11 for an update that adds a Do Not Sync checkbox in addition to or as opposed to a Remove From Client checkbox. I am on the razor's edge of dumping the whole project and going with something else, but as this is in the works I'll hold off on that, because I like the concept here.

slylabs13 on 15 May 2017

@tflidd I think you need to think the other way around. The files originated on the local machine first. It really isn't like your scenario with music files at all. It's more like having created a shortcut to some server files, I decide I do not want the shortcut anymore and delete it. To my horror it also deleted the shared files! This is simply the wrong way to go about this, and if this is not going to change anytime soon, I have to abandon this project.

slylabs13 on 15 May 2017

I also find the behaviour dangerous because it can happen, that you accidentally even delete data which was not uploaded to the server yet.

I often deal with large scientific datasets which are to large to have them uploaded on my server. I evaluate them on my laptop and want the result files (which are a fraction of the size) synced to the server. So what I would normally do is copy the raw data directory on my machine, uncheck the raw data directory from uploading/snycing and have the result files synced to the server. But what happens when I do it like this is that the raw data is simply deleted and because it was that large, it wasn't even uploaded to the server before deleting it. Hence, unchecking this checkbox actually leads to data loss without a warning. Of course I can copy the raw data from the original machine where I acquired it (or from a backup), which is what I do. But still, I consider this behaviour very dangerous.

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.

@jancborchardt This is not prevented by this approach. I can still trick the client into having subfolders not synced in a parent folder which is synced by unchecking the subfolder, wait for its deletion and manually create it again. Then I can copy whatever I want into this folder without the client bothering and uploading. Sure, it was me who did it, so I should be aware, but maybe I forget 😉

raimund-schluessler on 18 May 2017

At this point I think you are wasting your breath. There are efforts to provide an alternate mode of operation, but it seems everyone in dev is very defensive about this. Everyone I have spoken to who sell, supports or uses cloud sync systems of all types are shocked to head OwnCloud/NextCloud works this way. I guess it's the choice of the devs to leave it like this and it's our choice whether or not to use it.

I think for small local document syncs this will work fine, but I would not recommend anyone with large datastores of critical data to use this.

Bob S

On May 18, 2017, at 07:31 , raimund-schluessler notifications@github.com wrote:

I also find the behaviour dangerous because it can happen, that you accidentally even delete data which was not uploaded to the server yet.

I often deal with large scientific datasets which are to large to have them uploaded on my server. I evaluate them on my laptop and want the result files (which are a fraction of the size) synced to the server. So what I would normally do is copy the raw data directory on my machine, uncheck the raw data directory from uploading/snycing and have the result files synced to the server. But what happens when I do it like this is that the raw data is simply deleted and because it was that large, it wasn't even uploaded to the server before deleting it. Hence, unchecking this checkbox actually leads to data loss without a warning. Of course I can copy the raw data from the original machine where I acquired it (or from a backup), which is what I do. But still, I consider this behaviour very dangerous.

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.

@jancborchardt This is not prevented by this approach. I can still trick the client into having subfolders not synced in a parent folder which is synced by unchecking the subfolder, wait for its deletion and manually create it again. Then I can copy whatever I want into this folder without the client bothering and uploading. Sure, it was me who did it, so I should be aware, but maybe I forget 😉

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

slylabs13 on 18 May 2017

Looking at these comments (one of which is mine):
https://github.com/owncloud/client/issues/2502#issuecomment-134257388
https://github.com/owncloud/client/issues/2502#issuecomment-134610381
https://github.com/owncloud/client/issues/2502#issuecomment-134901423
I tested again with ownCloud client Version 2.3.2 (build 6928)
1) Create FolderA and put some files in it.
2) Let them sync to the server
3) From the client, stop syncing FolderA - it stays on the server and is deleted on the client
4) Create FolderA again on the client, with some files in it.
FolderA and the files in it now have the "warning" color to indicate that they are not synced.

So that behavior is different from in 2015 (when such folders showed a red cross).

phil-davis on 18 May 2017

Users can do this sequence already, and do it purposely - e.g. in the case of having some big folders of "research data" among other folders, just create "bigresearchdatafolder" first (empty or with a little file in it), let it sync up to the server, unselect it from sync. Now make "bigresearchdatafolder" again on the client and put all your big files in it.
The user now has a folder on the client in which they can put files that will not be synced.
ownCloud client already has the logic underneath to cope with this, and display an appropriate overlay icon on the folder/files.

So rather than users finding this "workaround" by reading this thread, there could be an option added to let the user choose to keep the files on the client after unselecting them from sync.

It would need some global option also to enable/disable this behavior, and perhaps a branding override so that a company can make clients that do or do not have this behaviour.

phil-davis on 18 May 2017

I've been using the same sequence as @phil-davis with mixed results. Either:

It will work and the folder contents won't be synced, and the folder overlay icon is showing info
The client will still sync the files to the server and delete all the local files in the folder or most of them, the folder icon will show synced

Adding the folder names to the ignore list isn't an option since some of the folder names are too common and folders I want synced would be ignored.

s1rc on 31 May 2017

Actually, @s1rc I do not need this myself, but it is what can happen to users unexpectedly (who do not really know what they are doing, have unselected a folder from sync, wonder why it is not there and recreate it empty locally and start putting files in it) or purposely (e.g. for big files like int the example above).
But I have not seen it cause an issue server-side once it is "set up", as long as the user does not accidentally choose again to sync the folder.

phil-davis on 31 May 2017

@phil-davis I do agree, it can be confusing for users who see their files disappear.

I have been using this workaround since I started using Owncloud. I have folders many files, sometimes in the tens of thousands that don't need to be synced. Yet even with that folder unchecked the client syncs the files and deletes the local copies.

s1rc on 31 May 2017

@s1rc If you can replicate the problem then log it as a separate issue. I tried various restarting the client... and my now-unsynced local folder always stays there, and is deselected from sync to the server.

phil-davis on 31 May 2017

See #5810 for a little issue with hw the overlay icons appear when users (purposely) do this sort of thing.

phil-davis on 31 May 2017

Just lost a good amount of work because of this, __not deleting by default__ is also a good idea.

benrob0329 on 5 Aug 2017

Just lost a good amount of work because of this, not deleting by default is also a good idea.

The client only deletes when the file is the same as on server.
Can you go into detail which behaviour you saw exactly?

guruz on 7 Sep 2017

Set up a local folder with subfolders to sync. After the sync, suddenly see subfolders you do not want or need synced. Uncheck subfolders. Watch in horror as your local files are removed from the file system. Of course, you can re-check the subfolders and they reappear, but now I feel like I had sex with a girl who now threatens to destroy my like if I ever leave her.

Bob S

On Sep 7, 2017, at 05:25 , Markus Goetz notifications@github.com wrote:

Just lost a good amount of work because of this, not deleting by default is also a good idea.

The client only deletes when the file is the same as on server.
Can you go into detail which behaviour you saw exactly?

slylabs13 on 7 Sep 2017

😄1

Dear Bob, yes, if you have that feeling, I kindly like to remind you to what your mom probably was teaching you: Before doing something (the one, or the other thing) think a second if it is good for you ;-)

dragotin on 7 Sep 2017

...and on a more serious note: The files were added to the local harddisk through the sync, not because you put them there. Now they disappear again, as you removed them from the sync tree. I think that is very logic, and works as designed. But that is maybe just me...

dragotin on 7 Sep 2017

That is true if you are syncing files from another source. What if YOUR hard drive was the original source? Then it makes no sense at all!! And that is the key to any kind of sync. Who becomes the master? The original? The latest? In this case the devs decided the server was the master because they cannot account for all use cases (someone pushes files up from a temporary thumb drive for instance). What is really needed is a way to treat the original source files as the master until otherwise designated by the end user. Something like a Server Is Master checkbox by every folder.

Bob S

On Sep 7, 2017, at 07:49 , Klaas Freitag notifications@github.com wrote:

...and on a more serious note: The files were added to the local harddisk through the sync, not because you put them there. Now they disappear again, as you removed them from the sync tree. I think that is very logic, and works as designed. But that is maybe just me...

slylabs13 on 7 Sep 2017

👍1

I think the initial subject is a fair request: give us the option to remove the folder from the sync list and keep our local copy. It's debatable whether or not this should be the default or not - but I would be happy with just having the choice. It's part of why I host my own private cloud - because it's my data and my choice.

I've started a bounty for this here: https://www.bountysource.com/issues/6189424-unchecking-synchronized-subfolder-without-local-delete

DerekJarvis on 8 Sep 2017

Bob,
The issue is that ownCloud is not a "full mesh/distributed" sync solution. So if there is LaptopX, Server, TabletY, MobileZ, Laptop2... and LaptopZ is designated as "master" for some folder(s)/file(s) then there is no way for TabletY, MobileZ, Laptop2... to then be able to choose to get a synced copy of those files.

Solutions that keep some folders/files only locally on LaptopX (within what looks like an overall synced folder tree) need to make sure that users who do so will be "fully aware" of what they are choosing. And in the future can easily see somehow what is not being synced up to the server.

phil-davis on 9 Sep 2017

👍1

Consider the selective sync blacklist as a great visual interface for ignoring specific user's folders. So, this quick'n'dirty thing does it.

diff --git a/src/csync/csync_update.cpp b/src/csync/csync_update.cpp
index ae7efba77..ea253119a 100644
--- a/src/csync/csync_update.cpp
+++ b/src/csync/csync_update.cpp
@@ -147,7 +147,12 @@ static int _csync_detect_update(CSYNC *ctx, std::unique_ptr<csync_file_stat_t> f

   if (ctx->current == REMOTE_REPLICA && ctx->callbacks.checkSelectiveSyncBlackListHook) {
       if (ctx->callbacks.checkSelectiveSyncBlackListHook(ctx->callbacks.update_callback_userdata, fs->path)) {
-          return 1;
+          fs->instruction = CSYNC_INSTRUCTION_IGNORE;
+          if (ctx->current_fs) {
+              ctx->current_fs->has_ignored_files = true;
+          }
+          excluded = CSYNC_FILE_EXCLUDE_LIST;
+          goto out;
       }
   }

Unchecked folders are in place but ignored. Checking again synchronizes them. And it seems it doesn't break anything. I hope :)

dagayaru on 26 Dec 2017

👀1

dagayaru, I am not saavy with Linux. Is this a file I am supposed to create in the Linux file system? If so, where do I save it? I can SSH in so no problem there, I just need to know where to put it/save it.

slylabs13 on 26 Dec 2017

@slylabs13 yes it's a file to place into the desktop client source dir and then patch -p1 <file. And then go though the all building process to make your custom desktop client application.

dagayaru on 27 Dec 2017

I've stumbled across this thread after dealing with a lot of shit.
I decided to sync everything on my hard disk. I don't need to sync stuff like my AppData, so I naturally unchecked it. When the message came that it would remove the items locally, I didn't dismiss it because I was too lazy to try to comprehend what it meant, but because I just couldn't believe that OC would actually do that when it's a syncing client.

God is this an awful feature. Of course I don't want all my shit deleted. Of course this is the dumbest decision in human history.
I'm now forced to sync everything to make sure nothing is deleted and then delete OC from my pc until the programmers have thought about a normal way to handle the syncing process.

This method is insane

GustvandeWal on 13 Feb 2018

👍7 😕1 😄1

Welcome to the "Oh Shit!" club.

Bob S

On Feb 13, 2018, at 06:18 , Gust van de Wal notifications@github.com wrote:

I've stumbled across this thread after dealing with a lot of shit.
I decided to sync everything on my hard disk. I don't need to sync stuff like my AppData, so I naturally unchecked it. When the message came that it would remove the items locally, I didn't dismiss it because I was too lazy to try to comprehend what it meant, but because I just couldn't believe that OC would actually do that when it's a syncing client.

God is this an awful feature. Of course I don't want all my shit deleted. Of course this is the dumbest decision in human history.
I'm now forced to sync everything to make sure nothing is deleted and then delete OC from my pc until the programmers have thought about a normal way to handle the syncing process.

This method is insane

slylabs13 on 13 Feb 2018

I've been subscribed to this thread since early 2016 and am still dealing with this. How do issues like #6305 get closed so fast only for this to be ignored for over three years?

Calling this behaviour a feature is a misnomer. It's a bug, bad design, or both. If nothing about the behaviour gets changed, then at least the UI should be changed to better reflect the behaviour. I'll quote @mortee from August last year:

Ah, and I can't stress enough what also has been mentioned multiple times: deleting data as a result of unchecking some checkboxes (especially without unmistakable and unavoidable warnings/confirmation) is both unintuitive and recklessly dangerous. Which directly conflicts with the purpose of a system that is at least in part used for data safety/backup.

b12f on 13 Feb 2018

👍2

This one is by no means ignored. It comes up for review once in a while. Challenge is that the path is not clear at all. Opinions are exchanged and the current behaviour is the conclusion we have taken - new arguments or better ideas for a solution might change things. But please look at it from a market standpoint, a normal user standpoint and only last from your own point.
Data loss can and will happen if we don't delete, because people will put a file into the folder afterwards and it will not be synced to the server. Or they will miss a file, pick a wrong version, etc.
ownCloud is a Server/Client solution and we defined that the Server is the Master and basically keeps everything. Version, Trashbin, etc. essentially forever if you like. Therefor a deletion client-side is just an annoyance, never a data loss.
So please lets be more creative and see if there are ways which can fix both. Just thinking out loud an option could be to move such a folder under owncloud-nonsync and keep it there = Keep it on the disk, but outside of the /ownCloud sync folder. More creative input is very welcome - no desire to ignore anything just need a great idea which does not lead to data loss for less smart people.

hodyroff on 14 Feb 2018

👍1

Therefor a deletion client-side is just an annoyance, never a data loss.

My problem here is that this is not true. The client deleted data which was never uploaded to the server, effectively resulting in a major dataloss. I haven't checked for a while if this is still the case, though.

raimund-schluessler on 14 Feb 2018

👍5

The client deleted data which was never uploaded to the server, effectively resulting in a major dataloss. I haven't checked for a while if this is still the case, though.

@raimund-schluessler Sounds like a bug. If this is the case, then please open a new issue for it.

michaelstingl on 14 Feb 2018

I don't know if it helps rethinking this (I've been quite shocked too when I understood that my local files could be deleted as easily as this !), but I've been using rsync on Linux for a while. It does the job really well :

Deleted files on local are removed on remote backup if I tell it to sync as is
Deleted files are not removed on romete backup if I tell it to sync 'positive' (only created / moved files)
Moved / renamed files are moved / renamed on the remote backup

I don't know if Nextcloud is using rsync but it's a really good tool !

What I'd like to get is a switch button on the clien desktop that would say "sync from local to remote" versus "sync from remote to local"

This would pretty much do the trick as if I'm sure I want my local mirrored at some point, I would tell the client app to check changes on the local and mirror them on the remote, and vice versa, which wouldn't need anymore this 'remote is master' situation

EtienneSafa on 10 May 2018

👍1

This one is by no means ignored. It comes up for review once in a while. Challenge is that the path is not clear at all. Opinions are exchanged and the current behaviour is the conclusion we have taken - new arguments or better ideas for a solution might change things. But please look at it from a market standpoint, a normal user standpoint and only last from your own point.
Data loss can and will happen if we don't delete, because people will put a file into the folder afterwards and it will not be synced to the server. Or they will miss a file, pick a wrong version, etc.
ownCloud is a Server/Client solution and we defined that the Server is the Master and basically keeps everything. Version, Trashbin, etc. essentially forever if you like. Therefor a deletion client-side is just an annoyance, never a data loss.
So please lets be more creative and see if there are ways which can fix both. Just thinking out loud an option could be to move such a folder under owncloud-nonsync and keep it there = Keep it on the disk, but outside of the /ownCloud sync folder. More creative input is very welcome - no desire to ignore anything just need a great idea which does not lead to data loss for less smart people.

My scenario of using Nextcloud is that I want to synchronize my coding between my desktop and my laptop, but the settings is slightly different, so the setting files are not expected to upload and sync. To ease the solution based on the current work, my suggestion is that when the syncing folder pair is built, sub-folders already existing in the local folder but not in the server folder should not be included in the syncing targets and uploaded to the cloud server; Sub-folders in the server should be synced to the local . Sub-folders created after the folder pair is built should be included in the syncing target and synchronized anyway. In this way, time mark can be used and the solution is simple.

MRCSTJM on 13 Dec 2018

My scenario of using Nextcloud …

You're in the ownCloud repo here 😉

michaelstingl on 13 Dec 2018

@michaelstingl
Well to be fair. I'm using another piece of software too, but they are essentially clones with a different icon; not even a different skin.

GustvandeWal on 14 Dec 2018

@GustvandeWal I can only speak for the ownCloud project, and there we are investing heavily in the "Virtual File System" (VFS) approach. I don't think we'll see this ever implemented in the oC selective sync folder settings by checking and unchecking boxes. Maybe those use cases can be solved with a future implementation of the VFS, but what I read, NC has no plans to follow the VFS concept.

michaelstingl on 14 Dec 2018

Jumping on the "this is incredibly annoying" bandwagon. Here's my scenario. Laptop I use for work. I was setting up the folders I want to sync. Without thinking, I set up a sync on a folder that's already syncing with Microsoft OneDrive. "No big deal, I'll just uncheck it." Nope, can't do that or now I'll destroy the whole OneDrive folder that's syncing with my team. I think my only option is to uninstall NextCloud and reinstall, re-setup everything. Grrr.

Why can this simply be an option? I get it if most users expect the files to disappear, but why not a checkbox or something that says "[checked] Remove files from my local drive (they'll still be on the server)."

markmcb on 6 Apr 2019

👍3

I think my only option is to uninstall NextCloud and reinstall, re-setup everything. Grrr.

@markmcb No idea about NC. This is the ownCloud repository.

michaelstingl on 7 Apr 2019

I put a Virtual Machine folder into my documents folder without thinking. Now it takes for freaking ever to sync because it's trying to copy the VM! I don't DARE tell NextCloud to not sync that folder as it will delete the VM folder. The people who developed this model of sync will staunchly defend their position on this, but I cannot believe they thought through the consequences of this kind of sync model. My Documents folder is no longer my own. The NextCloud device owns it now.

Bob S

On Apr 6, 2019, at 11:47 , markmcb notifications@github.com wrote:

Jumping on the "this is incredibly annoying" bandwagon. Here's my scenario. Laptop I use for work. I was setting up the folders I want to sync. Without thinking, I set up a sync on a folder that's already syncing with Microsoft OneDrive. "No big deal, I'll just uncheck it." Nope, can't do that or now I'll destroy the whole OneDrive folder that's syncing with my team. I think my only option is to uninstall NextCloud and reinstall, re-setup everything. Grrr.

Why can this simply be an option? I get it if most users expect the files to disappear, but why not a checkbox or something that says "[checked] Remove files from my local drive (they'll still be on the server)."

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

slylabs13 on 8 Apr 2019

👍1

You could add an ignore pattern for your VM files.

dragotin on 8 Apr 2019

That's a workaround at best, whether you use the main Owncloud repo or the Nextcloud rebranding the behavior remains the same.

benrob0329 on 8 Apr 2019

+1 for changing this. We have a whole research group using this software and they all need to be warned about this behavior as nobody imagines their local copy will be removed by unchecking a sync box.
Something along the lines of offering 2 options per folder instead: "stop syncing to local machine" (i.e. removes local copy) and "stop syncing with remote machines" (leaves local copy only) would be a significant improvement on current behavior.

Mike-Devereux on 23 Jan 2020

👍1

Stumbled over this behavior today as I intended to create automatic sync of important folders from my local machine into my cloud server. But within these important folders there are of course subfolders which I do not want to sync, I just want them to stay local (no sync ever needed).

Now the behavior of the Sync client forces me to create folders outside my folder logic, which is insane.

I'm not a programmer, but seeing this kind of message telling me that if I uncheck a folder from syncing it will be deleted locally makes me angry. If I uncheck the folder, I do not want it to be uploaded to the server that's all. Local files stay local, never ever touch them!

Though it would be great when I add a Folder sync that the Sync client would allow me to select folders on my local machine which I like to sync including the option to uncheck any subfolders I do not want to sync. This would make this "...will be removed from your local file system..."-message obsolete as only the folders get uploaded which should be synced.

Right now I'm only able to select one folder on my local machine, but could not tell the sync client not to sync specific subfolders. Additionally I'm forced to sync something I do not want. Insane!

Though why not keep a simple thing simple, allow the user to select the folders which should be synced (including the selection of subfolders) and if they unsync these folders later, just give notice that they will only have to newest version locally. When user decides to sync the same folder again, just start syncing again from that moment on.

Anyway, I know building such software isn't easy and I highly appreciate the effort of everyone involved.

So please make this client more user friendly and intuitive to use. Remember, never ever touch any local files! It's not your business.

Thank you.

dpw1460e on 30 Jan 2020

Regarding earlier comments, I don't think a clever solution is necessary here, just the straightforward option to override the default behavior if an experienced user wants to accept the risks and clicks away any warning popups ("advanced" or "expert" option hidden by default if you like).

In the current scenario OC effectively assumes that the user can't be trusted to look after their own data, and they shouldn't even be given the option to try as they'll just mess it up and blame OC, which is quite patronizing.

In my experience most users accept the consequences if they actively override the defaults and make an error.

Mike-Devereux on 30 Jan 2020

This really needs to be taken seriously. Still in 2020, I have to either upload my whole drive, delete local files, or temporarily move files off the drive. A decent workaround is to use "Ignore Files" to tag specific directories you want to "uncheck" without deleting.

As a side note, I just moved my Nextcloud to another server. When you combine the way it handles WebDAV, Modified Dates, S3 storage, and finally this client sync, it was excruciatingly painful. I really want to love Nextcloud, but it's getting harder these days.

Doc-Saintly on 29 Feb 2020

This is terrible. Why can I not choose certain sub-directories to not sync without deleting them locally? I have a lot of simulation data that I keep in sub-directories within my ownCloud directory. I do not need them on the ownCloud server, but I do need them locally. I tend to get a lot of errors when OC tries to sync these sub-directories, because they have thousands of files or many GB of data. Okay fine, no problem, I don't need OC to sync them, so I'll just uncheck. Except WHOOPS there goes all my data! Sure, I re-downloaded it from the OC server, but since the REASON I wanted to not sync it was repeated errors from OC, it's not 100% of my files. I'll have to redo hundreds of simulations by my guess.

This is terrible behavior. Files are created on my local machine. My local machine should be the master! Or at least I should be allowed to have SOME option to choose it to be so. Currently my only workaround has been to remove the folder sync connection and add it back, as at that point you can unselect certain sub-directories from syncing and get the expected behavior of maintaining locally and not syncing to server.

nora-anne on 15 Apr 2020

👍1

I'm on mac catalina. I started a folder sync of my Downloads folder but one of the subfolders had 50gb of video that was mostly already on the server under a different Videos folder. I thought that the easiest way to merge the folders would be to go through with the sync for Downloads and then copy the subfolder over and look for an option to skip files already at the destination. I didn't do this because I was concerned that I would generate 50gb of versioned files in Downloads. Instead I unchecked the subfolder in Downloads because I wanted to sync it with Videos folder instead.

I was panicked to see this delete my local files and I can't find them in the Trash.

Does the macos nextcloud client move deleted files to the trash?

Does moving files in nextcloud leave version files?

What happens if I create a new sync connection between two folders with items in the local and the remote?

goldycode on 3 May 2020

The solution for you now is to re-check the folder that deleted the files, resend to get them back, then stop using NextCloud altogether. Apparently the NextCloud developers decided that once you sync your files, NextCloud server becomes the master store.

Many people are aghast to discover this, and it is probably the one big reason NextCloud has not been more successful, but pleas to the devs only result in something like, “That’s how NextCloud works.”

I can see the difficulties in sync systems. For instance what should happen if two computers tap into a NextCloud share and sync, then both edits a file? In my opinion the original source should ALWAYS retain it’s status as the master. But then what if a second computer CREATES a file? Who is the master then?

The easy way out for the devs to get around all this is to make the NextCloud server the master.

Bob S

On May 2, 2020, at 5:38 PM, goldycode <[email protected]notifications@github.com> wrote:

I'm on mac catalina. I started a folder sync of my Downloads folder but one of the subfolders had 50gb of video that was mostly already on the server under a different Videos folder. I thought that the easiest way to merge the folders would be to go through with the sync for Downloads and then copy the subfolder over and look for an option to skip files already at the destination. I didn't do this because I was concerned that I would generate 50gb of versioned files in Downloads. Instead I unchecked the subfolder in Downloads because I wanted to sync it with Videos folder instead.

I was panicked to see this delete my local files and I can't find them in the Trash.

Does the macos nextcloud client move deleted files to the trash?

Does moving files in nextcloud leave version files?

What happens if I create a new sync connection between two folders with items in the local and the remote?

slylabs13 on 3 May 2020

@Doc-Saintly @goldycode @slylabs13 You're in the ownCloud repo here 😉

michaelstingl on 4 May 2020

Client: Unchecking synchronized subfolder without local delete

Expected behaviour

Actual behaviour

Steps to reproduce

Server configuration

Client configuration

Most helpful comment

All 103 comments

confusion

discussion

what can be done?

What would you expect:

What happens instead:

What is the point:

Links:

Related issues