We hear you, I will forward this on to our development team to consider.
1 Like
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?
7 Likes
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. 
6 Likes
Has there been any progress on addressing this issue?
3 Likes
@Tom hello Tom
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.
(*) borrowed from Full Sync vs Backup - #21 by Stu_8
2 Likes
I agree as well. I am currently looking into alternatives, because with IceDrive the risk of losing important data is just too high right now.
And the fact that we even need to explain the importance of this doesn’t give me confidence in the team at all.
4 Likes
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.
Screenshot from FreeFileSync:
Thanks for posting this workaround!
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.
1 Like
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.
I’ll re-test and report back. Fingers crossed.
1 Like
Thanks for the FreeFileSync tip.
That might be the workaround I’ve been looking for.
I can go about my business…
1 Like
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.
2 Likes
@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.
2 Likes
Good thinking! I hadn’t considered that, but I don’t think it will be a huge problem long term. Definitely on the initial re-upload, I’ll want to do it in chunks and clear temp, rather than attempting to upload all 2TB at once. But after the initial upload, I think regular sync shouldn’t be a huge problem with extra space.
And yeah, I hear ya, I wouldn’t be running a comparison based on “content” frequently but it’s nice to know that it works without issue if and when needed. “Size and time” seems to do the basics just fine.
Here’s more info about how RealTimeSync (part of FreeFileSync) works: FreeFileSync . I think you can technically have it do just about anything when it detects changes to a monitored directory, but the default is to run a freefilesync batch job. So that being the case, it would pick up any changes made even when it wasn’t running, but only once it’s triggered by another change in the directory being monitored when it is open. Because from there on out it’s just a standard FFS sync based on whatever parameters you’ve set. Just saves the user a step and triggers the job for you.
Not perfect, but a step forward at least.
2 Likes
Ah, right. That is indeed better than Icedrive’s behaviour, albeit not perfect as you say. For further peace of mind one could perhaps add a “scheduled batch job” that scans everything, say, once a day. 
Anyway, I think I will just go with the sync pairs for now, combined with occasional “manual” checks using FreeFileSync. Let’s see how that goes…
1 Like
So we’re out here figuring out ways to make IceDrive work the way it should, with not a peep from the IceDrive team. 
3 Likes
