[Bug]: Directory is already being used as a sync folder.
⚠️ Before submitting, please verify the following: ⚠️
- [x] This is a bug, not a question or a configuration issue.
- [x] This issue is not already reported on Github (I've searched it).
- [x] Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
- [x] I agree to follow Nextcloud's Code of Conduct
Bug description
I cannot add a directory for syncing after removing it.
Steps to reproduce
- Open Settings -> Standard file sync
- Add folder sync connection
- choose a directory
- let it sync
- remove the directory
- try to add it again
Expected behavior
The directory should be synced.
Which files are affected by this bug
N/A
Operating system
Linux
Which version of the operating system you are running.
Arch Linux + GNOME 47
Package
Official Linux AppImage
Nextcloud Server version
30.0.4
Nextcloud Desktop Client version
3.16.0
Is this bug present after an update or on a fresh install?
Fresh desktop client install
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
- [x] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other
Nextcloud Server logs
Additional info
No response
This is working as expected. Using the same sync folder more than once can lead to issues and even data loss. You need to pick a new location to sync your files to.
This is working as expected. Using the same sync folder more than once can lead to issues and even data loss. You need to pick a new location to sync your files to.
Lmao
If anyone comes across this and finds this hilarious response from Nextcloud, go to your previously synced directory and delete these hidden files.
Imagine if Google drive made you do this.
⬆️ see the workaround (the second one of the hidden replies) ⬆️
I actually need this with Windows and Linux in dual boot. Since I had to reinstall Linux, I downloaded the most current apt package and it showed this error. apt version downgrading seems to be hard, so now I went with the flatpak version which is quite easy to downgrade (3.12 is what I chose). I'm adding the directories now, and then I'll update again. Wasn't sure if I could just delete the db files so now I'm using an outdated version instead.
I'm sorry, but this shouldn't have been closed - it is most definitely a bug. It is not possible to add the folder again after removing it from the sync. I don't know how this leads to issues; and it shouldn't lead to issues, as the syncing should compare the files locally and remotely anyway. The folder shows up as being synced when selected again, but it does NOT sync at all after it is once removed. That cannot possibly be intended.
I, for example, removed the folder because the client kept crashing. It is apparently not good at syncing 500 GB folders all at once, although that's pretty much its only purpose. After having removed it I had to manually delete the files in the local folder as roasted watermelon said. That is not well designed from a user perspective. @camilasan please reopen issue.
If anyone comes across this and finds this hilarious response from Nextcloud, go to your previously synced directory and delete these hidden files.
Imagine if Google drive made you do this.
FWIW -- I came across this issue because I had the same problem.
Doing as this poster said fixed the problem.
There's an actual issue here -- that stale sync status files can exist, and the error message is obtuse.
That is not well designed from a user perspective.
We can improve the client behavior but at the moment it is working as designed, therefore it is not a bug.
Well, if a previously synced folder is marked as synced despite not having any sync enabled anymore, I'd call it a bug. But I agree that the client behaviour can be adjusted to reflect this better. How about a warning saying "It looks like this folder is already being synced. Do you want to continue anyway?" rather than just refusing to do it altogether.
my comment which was the actual solution being hidden as "abuse" is wild
Of course, it’s all a question of how you define “bug”. Technically, if it’s working as designed, then, yes, it’s not a bug, in the same way that Y2K wasn’t technically a bug either. If, however, what it’s designed to do is problematic, then calling it a bug is probably more polite than some of the words that came to my mind.
@roasted-watermelon I copied my sync folder to a new file, and the hidden sync database stopped me from using the new location until I found your [bug, whatever-you-like-to-call-it] report. Thanks.
Of course, it’s all a question of how you define “bug”.
Sorry, no. The engineering team might have decided on a requirements document and therefore it's a feature, not a bug.
But -- this behavior is surprising behavior. Meaning, the application is violating the principle of no surprises. The user is left with no clue as to what's going on, and is going to start tearing their hair out trying different things to fix this issue. The behavior described above, "It looks like this folder is already being synced. Do you want to continue anyway?", would be a great choice.
Imagine if Google drive made you do this.