Unchecking synchronized subfolder without local delete

[ts-mk]

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

1. Set up a folder to be synchronized with the server.
2. Later click on "Choose What to Sync" for that folder.
3. Uncheck subfolders that you don't want to synchronize anymore.

   Server configuration

Operating system: Ubuntu 14.04 Web server: Apache Database: SQLite PHP version: 5.5.9-1ubuntu4.5 ownCloud version: 7.0.2 Storage backend: file system

Client configuration

Client version: 1.7 Operating system: Ubuntu 14.04 OS language: English

[luciamaestro]

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

[ts-mk]

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.

[jaranta]

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]

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.

[moscicki]

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]

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.

[dragotin]

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

[moscicki]

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

[phil-davis]

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.

[jancborchardt]

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.

[MTRichards]

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.

[moscicki]

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

[phil-davis]

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.

[MTRichards]

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

[MTRichards]

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

[moscicki]

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

[dragotin]

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.

[gunwald]

@moscicki I agree too, it is a serious bug, and I decided to not use owncloud till it'll be fixed. It's absolutely unacceptable, that local files are deleted only because of the fact, that I don't want them to be synchronised. And I gues that nobody aspects that behaviour. The worst thing is, that at appears to me that this behaviour was introduced only in 2.0. So imagine that with one click I could delete accidentally thousands of important files. Please fix that and be more careful with such »features« in future.

[dragotin]

@gunwald did you read my last comment?

[gunwald]

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

[phil-davis]

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

[MTRichards]

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

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

[gunwald]

@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

[scolebrook]

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.

[ts-mk]

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

[moscicki]

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

[scolebrook]

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

[ts-mk]

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

[moscicki]

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

[scolebrook]

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

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

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.

[moscicki]

@scolebrook: makes sense!

[gunwald]

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.

[scolebrook]

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

[tflidd]

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?

[sprocket888]

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.

[mortee]

+1 for the original request

[martin-rueegg]

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:

1. 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
2. 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
3. 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
4. the current column Size will be renamed to e.g. Remote Size
5. 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.
6. all folders and files are selected by default and will be merged (conflict handling?)
7. 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.
8. 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.
9. 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
10. 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.
11. all changes (deletion, blacklist and ignore list additions) would only take effect once the user confirms adding the sync folders.
12. 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.

[Frank-Zappa]

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.

[naomiyoshida]

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:

1. You set up an (empty) instance of the Owncloud server.
2. You connect device A to it, say a desktop Computer.
3. 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.
4. You may connect a second device B to your Onwlcoud instance, say a notebook with a small HD.
5. 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?

[martin-rueegg]

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:

1. You set up an (empty) instance of the Owncloud server.
2. You connect device A to it, say a desktop Computer.
3. 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:

1. set up a server (empty)
2. 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
3. repeat step 2. on other clients (slaves)
   • now the files of the master client get synchronised to the slaves.
4. 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).

[pierv]

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 !!

[guettli]

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!

[tflidd]

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

[moscicki]

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

[b12f]

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.

[guettli]

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

[moscicki]

Ignore list exists already:

The overall discussion is more complex of course.

On Thu, Aug 11, 2016 at 11:41 AM, Thomas Güttler notifications@github.com 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