Expected behaviour
If I select a folder (âAâ) to synchronize with server and later decide not to synchronize one of its subfolders (âA.Bâ), I might not want local files to be deleted. Just because I donât want something to be synchronized anymore doesnât necessarily mean I want it to be removed from my local machine.
Actual behaviour
Currently there seems to be no option to do that (apart from removing folder A completely and setting it up again while unselecting subfolder A.B) so it would be great if the user could somehow choose whether local files are to be deleted.
Steps to reproduce
- Set up a folder to be synchronized with the server.
- Later click on âChoose What to Syncâ for that folder.
- Uncheck subfolders that you donât want to synchronize anymore.
From: Unchecking synchronized subfolder without local delete · Issue #2502 · owncloud/client · GitHub
I have found some posts from an interesting discussion from the help forums: Unchecked folders will be REMOVED from your file system
Again I want to stress, this CANNOT be the way this works, or users will be losing files constantly and wonât know why. NO WAY any solution should remove local files. The LOCAL files should ALWAYS be the master.
NO SOLUTION should delete local files simply because a checkbox is unchecked
I am never going to convince developers there why this is such a bad idea, so I simply will not use this product.
I have reviewed several cloud systems. Absolutely none work the way NextCloud works. They canât. No one would use them. No one would take the risk. There is a scenario where someone could uncheck a folder, delete the local files, not know what to do, and so delete the account on the nextcloud server, thereby permanently losing their files.
This user from 2017 is absolutely right.
New post from user hcoin:
"If the original source of every file was the server (think ânetflix movie downloadsâ) the idea files âgo away when the connection goes awayâ feels normal. When answering this question above we see the nextcloud devs narrow the timeframe they allow in their thinking, they begin with the assumption that the âserver was the sourceâ so ânaturallyâ clients disconnecting wouldnât want the files from there anymore either. This is of course a logical impossibility, the server is never the source, phones are the source of nearly all photos and video clips, desktops are the source of nearly all documents.
Also, we read ânextcloud isnât a backup solutionâ proposed as the reason why deleting files from the clients when the server connection is broken âmakes senseâ. This has the same feeling of being told since cars are not trains you shouldnât travel. Youâd think if nextcloud authors didnât want the nextcloud server to be relied upon for backup they would be more likely to provide a way for disconnections to retain local files, not less.
I think the âreal reasonâ for deleting files on the clients upon disconnection is having to face the daunting logic puzzle of nextcloud being presented with âa new directory to syncâ already populated with a great may files that already exist on the server. Is a file with the same name and with different content and an older date than one on the server â but in âa newly presented directoryâ-- âwhat the user really wantsâ or would they like that file on the local system replaced with the ânewer one with the same nameâ on the server, or renamed then uploaded to the server as the older file? Or uploaded to the server as âan older versionâ then âthe new oneâ replace it⊠or⊠maybe require all newly connected directories that already exist on the server only if they contain older content to be renamed on the client, then the new âemptyâ directory on the client populated with whatâs on the server?
Coming up with an answer to that one that âisnât confusing to most peopleâ â thatâs I think the real issue preventing the right thing from happening here: Certainly at least on desktop systems DO NOT DELETE CLIENT FILES upon disconnection by default, ever. If I was coding this: Upon connection of a new directory to the server, any file on the client thatâs older than on the server, for which a prior version doesnât already exist on the server, should be uploaded as an older version then replaced with the latest on the server. If âversioningâ isnât enabled on the server, then if a non-empty directory is presented for connection to the server that already exists on the server â rename the client directory and create an empty one with the name on the server and populate it from the server, let the client figure out what to do with the files in the âoldâ directory."
Also reported at Owncloud (same issue) - but they do not fix it. See Unchecking synchronized subfolder without local delete · Issue #2502 · owncloud/client · GitHub