Has anyone else noticed this?
If the Icedrive app is closed and files change in a sync pair, the app doesn't pick up and sync those changes when it's restarted.
Steps to reproduce:
Quit the app.
Add some files in a sync pair.
Reboot.
The app won't see the new files. It has to be watching at the time the changes take place.
The workaround is to move the files elsewhere and move them back again. But this isn't feasible if there are lots of changes to keep track of.
I often need to quit the app to avoid a conflict with Win32DiskImager, so it would help if this could be fixed.
As mentioned in your support ticket, currently, if the app is shut down and changes are made in synced folders, those changes won’t sync upon reopening the app. The app must remain running for syncing to work properly, but we’re exploring ways to improve this in future updates.
This is a very important feature. I guess I could get around this by using syncback. Or delete and re-create the sync pairs every now and then. But I don’t think I should have to do this.
The older versions of the app supported this kind of behaviour just fine.
I don’t think you’re seeing the importance of this bug. This isn’t something to consider, it’s a major bug that prevents normal operation. It’s too important to be merely considered.
It’s unreasonable to expect that everyone runs your app all the time. Anyone could turn it off at any time. When it’s resumed, the user will reasonably expect it to catch up with anything it’s missed.
I can’t be expected to recreate all sync pairs to capture files that might have been overlooked.
Can you recommend any third party software that can cover this shortfall?
I agree with @lawgiver_ai. This is a major issue that needs to be solved as soon as possible. It is also the main reason I don’t recommend Icedrive to my friends, to be honest.
Also, I think Icedrive should be much more transparent about this issue, instead of letting people figure this out for themselves. I am sure there are a lot of users who assume that their backup is accurate, while in fact it is not.
i think @lawgiver_ai is correct especially as the app is still not automatically starting up in a mac even with version 3.22 installed whereas in windows it does do that wen you turn on the pc
so on a mac you definitely risk losing syncs
While we are waiting for the Icedrive team to fix this problem, here is a tip*: check the integrity of your backup regularly with third party software, like ViceVersa Pro or FreeFileSync. This can be done by mounting the cloud contents in your file explorer, and have the software check for discrepancies between your local drive and the mounted one. I use FreeFileSync, which works like a charm.
But beware: if you decide to unmount afterwards, Icedrive will stop syncing correctly. (See bug report Be careful when you hit the Unmount button.) If you want to unmount, close the Icedrive app and restart it instead.
Hello, Can you explain what parameter you use to compare with FreeFileSync. If the file are encrypted, there is always extra few bytes that made the comparison to fail. Thanks in advance
Sure. You can set FreeFileSync to compare files by their metadata (time and size), rather than their actual contents, in which case there should be no problem with encryption.
I’ve had great luck with FreeFileSync as well, but only when working with the unencrypted side of icedrive. I’ve tried what you said here and adjusted the comparison criteria in FFS, but with no luck. The problem is that the encryption seems to add a few bytes to each file. Enough that the file sizes on local will never match with encrypted files within icedrive. Have you found any other solution for this?
That is odd! I have no clue why it is different for you, but here is a wild guess: could it be that you were using an older version of Icedrive when you created the sync pairs? I have created my sync pairs only recently (17th Oct. 2024), probably using version 3.22. There might be a difference in how the metadata are stored during encryption, compared to earlier versions of Icedrive.
For completeness: I am using Windows 10 and the standard file explorer that comes with Windows.
Awesome, thanks for the added details. The situation I described was accurate as of the last time I checked it out, which was admittedly months ago. I started to move everything over to the unencrypted side of icedrive in order to make use of freefilesync, encryption be damned. I haven’t revisited the encrypted side since the app update. I was also hoping/depending on the new sync and mount issue to make third-party apps unnecessary. But, well, we’ve already discussed how that’s going.
Thanks for sharing the parameters. I need to test with encrypted folders. As mentionned, maybe something has changed with the latest versions of IceDrive
I retested and for each individual file same date but different size. So FreeFileSync considers the fil eneed resynchronisation. There is no way in FreeFileSynch to test on date only. I have requested this option a while ago and never got an answer.
@Guido Success! I just re-tested. Your hypothesis seems to be correct. When comparing using the parameters you showed on files created in the “encrypted” side of icedrive with versions 2.xx, there is always a mismatch in the filesize between the encrypted icedrive files and my local files. HOWEVER, when I delete those directories and files and re-create them under the encrypted folder using the “mount” feature in the new icedrive 3.xx, and then compare with freefilesync, they match perfectly! This works when using any of the comparison parameters in FFS now, even “content”. This is a fantastic improvement that now gives me a usable solution to have encrypted backup that I can be confident is synced correctly, using FFS and icedrive only as “mounted”.
Tagging @lawgiver_ai , @pvdb64 , @FrankS , and @AlphaBeta so they see this. @AlphaBeta , if you’re still having the same results when using FreeFileSync, I’m guessing you haven’t recreated the encrypted folders and files. Try deleting everything on the encrypted icedrive folder and starting again from scratch and you should be good to go.
For anyone else looking for a real solution for encrypted sync: I think the best bet now is to do it this way-- delete everything from the “encrypted” side of icedrive if it was created with the 2.xx versions of the app. While using icedrive 3.xx with icedrive mounted and encryption unlocked, use freefilesync to do a one-way mirror of whatever you want from local to the icedrive encrypted folder. From here on out, you can actually use FFS to sync to icedrive encrypted without the filesize discrepancies. If you want a more hands-off sync solution, you can also use freefilesync’s “realtimesync” feature and set it up basically like you would set up icedrive’s sync pairs. But, you know, reliable instead. Hope this helps.
@tambo Great to hear! Looks like we have found a way to keep our backups accurate.
Also, interesting idea to completely bypass Icedrive’s sync pairs and let FreeFileSync do the job. There is however one caveat: without sync pairs Icedrive will create a lot of temporary files. That is, everything you copy to the mounted drive (either manually or by means of FreeFileSync), will not only be uploaded to Icedrive’s servers, but also appear in a temporary folder on your pc—the location of which can be found in Icedrive’s settings. As a result, the temporary folder might explode and one could run out of disk space. Possible solutions:
Delete the temp files regularly. It looks like this can be done safely, although I have not tested this thoroughly.
Move the temporary folder to a drive with enough storage space.
Use Icedrive’s setting “economical caching”? (I haven’t tried this.)
Stick to Icedrive’s sync pairs.
Yes, but with the same caveat: a comparison based on “content” will trigger Icedrive to download the files to be compared into the temporary folder, which takes a lot of time and consumes a lot of disk space. Fortunately, a comparison based on “size and time” does not trigger any downloads.
Thanks, I didn’t know FreeFileSync can do that! However, I suppose (correct me if I’m wrong) that this tool should be running continuously as well, in order to keep your back up accurate. It probably won’t notice any changes made when it was not active.
