Sync only picks up if app is running when files changed

Bug Reporting
,
#41

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:

screenshot FFS 30-11-2024
screenshot FFS 30-11-20242042×266 35.7 KB

The settings for the comparison should be “date and size”:

afbeelding
afbeelding756×245 21.6 KB

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:

afbeelding
afbeelding1125×291 43 KB

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.

1 Like
#42

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?

#43

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). :thinking: (tagging @Abe here)

1 Like