It is certainly a possibility to completely rely on FFS for the syncing process. I think that @tambo is exploring this route. However, I still use Icedrive’s syncpairs, and use FFS to “check and correct”. So every now and then I have FFS compare my local drive with my mounted drive (which in fact represents the cloud), like this:
If FFS finds any discrepancies, I hit the synchronize button. Make sure that the settings for synchronization are set to “mirror”, so that FFS only syncs in one way, and leaves your local drive undisturbed:
Good question. I think it does, because I assume that the mounted drive reflects exactly what lives in the cloud. It doesn’t contain files itself, but is more like a portal to the cloud. (Can anyone confirm this view?) So if FFS finds no problems, the local drive and the cloud should be exactly the same. Having said that, there is still the problem of file corruption (see the comment by @Abe above), which FFS probably won’t detect.
Why wouldn’t it detect corruption? Is it because a corrupted file could still have the same date and size? And, if so, what’s the issue with a content comparison?
Yes, if the corruption means that one bit is changed (from 0 to 1, or vice versa), the file size is unaffected.
The issue with the content comparison is that FFS will try to access the files on the mounted drive, which in turn triggers the mounted drive to download them into the temp-folder and decrypt them. That is not a problem per se, but it takes a looong time and your temp-folder will explode.
However, now that I think about it, it may be worthwhile to do this anyway, once in a while (once a year or so). (tagging @Abe here)
According to the changelog, the app should now track changes made when it is not running:
“Sync: Background monitor implemented to track changes in files and folders when the app is not running, and sync when app is reopened. Windows and macOS supported.”
I upgraded to version 3.31 and did some tests. However, it still doesn’t work for me. I have waited for at least 12 hours, but the app doesn’t seem to scan my folders for changes. Are others having more success?
I thought we were also waiting on a return of the scheduled sync functionality. It seems they’ve doubled-down on detecting running changes.
Maybe it’s me, but I think there’s something messy about having two apps running to provide one service. Version 2.x was a single app that did everything and did it well.
If this new background service were to crash, would we have visibility? Or, at least, visibility at a time when it mattered? At least if the main app crashes, we know about it - and a scheduled sync is guaranteed to pick up any missed changes.
It’s already been discussed there was recognised demand for a scheduled sync, but we’ve had silence since.
completely agree, a reconciliation full sync after the client startup would seem to me to be a more robust solution. that seems to be the way other cloud providers work but as long as this way does work i’m not too bothered. and i think we would probably have visibility if it did fail. when i upgraded to 3.32 yesterday, the upgrade didn’t ask for a reboot (it probably should have) as when i started the client, it did alert that the monitor service wasn’t running so the client must do some checking, which is why i rebooted and that defined & started the monitor service.
I can confirm: it works now! Our prayers have been heard. Very happy with this upgrade. I didn’t need to reboot by the way.
EDIT: While version 3.32 is certainly an improvement (it protects against accidentally shutting down the app), I must agree with @lawgiver_ai that it is still not watertight. The best solution remains to scan all folders from time to time. Even more so because the syncing process seems to be unreliable even when the app is running (see my previous post).
I had another crazy thing happening. Two days ago I added a big 30 GB folder to my local folder that is synced to Icedrive. It took about a day to upload it, I think.
Today I checked and none of it seemed to be in my Icedrive.
Turns out it had all been moved to the trash for some reason…