I’ve got a fresh install of e 2.8 on a fajita. I have my own nextcloud instance that I’ve been running for years, and used the built-in sync to connect in /e/ to connect to the nextcloud.
It’s great, everything got picked up and syncing seems to be happening. However, deleting files on the phone isn’t deleting on the server side. To me, this seems a little unexpected, as I would consider things ‘out of sync’ as soon as this condition occurs. The folders on the phone and on the server now have different contents.
Is file deletion delayed by x number of hours or days? Is there a setting somewhere that controls deletion sync behaviour?
I’ve done a bunch of searching to try and solve this, but no detail I’ve come across seems to quite match. My presumption is that it must be working for most, especially if you are using a paid setup with a quota and need to ensure you don’t run out of space in the cloud…?
last I checked in Sep 2023 (for bi-directional sync) the logic was in Remote- / LocalContentScanner.java here. There used to be a REMOTE_DELETE sync type that got removed here - so I guess no, no deletions on the remote when locally not found. There’s a linked MR to read upon for reasons. I can be wrong if new code is used since but I can’t find it on a whim.
can’t find much of a discussion on it (gitlab label on eDrive): Issues · e / Backlog · GitLab - I think the code at hand is final in what it can do
There was a very long thread with slightly different questions, but the official doc page on sync/eDrive doesn’t have much on behaviour still - Murena cloud syncing in one or two directions? - #11 by Manoj … but again, the code speaks for itself.
Nextcloud has bi-directional options in its client that will sync deletions both ways (if the option is checked for the folder)
But, I don’t know how well that’s doing with syncing. I can’t imagine it’s not supposed to work. I’m almost tempted to file an issue at this point to see if the problem is replicable and something that should be fixed - but I’m going to do a little more work trying to validate the issue.
the periodicScan code is still in main branch and reachable via WorkLauncher.kt - see the Readme for activity to trigger. Imo FileObserver is an alternative method that doesn’t rely on a interval schedule? but looking at logcat as you trigger either the FORCE_SCAN or Observer intents and see the log messages things will be clear.
I do look at handleFileDelete in FileEventHandler.kt and I think it will not go into a remote delete, but DISABLE_SYNCING - as it’d do in the periodicScan methods. To me it reads like “do not engage” in the sqlite db that holds state. You’ll see the removal of “REMOTE_DELETE” sync type in that observer file too before refactor. It survived the refactor.
I appreciate you look into the code, but nothing beats debugging probably. I’d still say from what I saw that there’s no remote removal, but I haven’t run eDrive for long now to know intuitively from usage
