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.
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.
Thanks for the FreeFileSync tip.
That might be the workaround I’ve been looking for.
I can go about my business…
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.
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.
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…
So we’re out here figuring out ways to make IceDrive work the way it should, with not a peep from the IceDrive team.
That baffles me as well. So far, the Icedrive team has shown no concern at all for issues that lead to incomplete backups. It’s hard to conclude anything else than that they just don’t care about our data.
And me.
Maybe I’m being naive here, but I think we should give them the next version or two to sort this out.
I just have this fantasy that their radio silence indicates focus. To be fair, they did indicate that they’d noted the demand for the timed syncing before this thread.
While I’m on this thread, though, can I ask what advantages FFS gives over Syncback? The reason I ask is that I already have the latter installed, so I’d like to use the same tool if possible. I simply haven’t had time to evaluate FFS yet, but I see some encouraging posts here, so it’s definitely on my radar. It’s just that I’ve been using Syncback for years, so I’m used to it.
I hope you are right! In the meantime, however, I would expect them to warn users about this shortcoming in the software. A simple email to all users would suffice. Or a warning in the app that pops up when you try to close it. Or something about it on their website. But strangely, they do none of that, as if they try to hide the problem instead of being transparent about it.
I wouldn’t know. I picked FreeFileSync more or less at random, being a free and decent looking app. Quite possible that Syncback does the job as well. Let us know if you give it a try!
It’s hard to conclude anything else than that they just don’t care about our data.
Agreed. Which, given the industry they’re in, is a wee bit problematic.
Alternate take: Maybe it’s just an extra layer of security, end-to-end-to-end encryption if you will. Where the final “-to-end” is plausible deniability of whether you ever actually had any data backed up in the first place. It’s Schrodinger’s data, if you will. It exists in a quantum superposition of backed up and not backed up until it is observed. If this is the case, their commitment to privacy in this regard is truly unparalleled.
@lawgiver_ai I love your optimism. Unfortunately, I don’t share it. I would be a lot more optimistic if this was the first time around. But I and many other lifetime users have been giving them “the next version or two to sort this out” for YEARS. Again, I think they are good folks who are trying to do their best, but they just can’t seem to stop screwing the pooch on sync. It has NEVER worked well, and since 2.70, there have been consistent regressions in functionality of sync in literally every single release since. (I would cite sources for that, but their changelogs barely exist and only came into existence after continued user pressure through conversations like this, and even now that they exist, seem to be an afterthought at best.) For over a year, they replied to every complaint or issue about sync with “this will all be fixed in version 3.” Version 3 is here, and here we are having these conversations. I’ve been a lifetime user for 4 years, always waiting for them to sort it out in the next version. At this point, it’s not worth any more energy. They seem to have gotten the “mount” feature solid, so I say we lean into their strengths. I’m going to treat that as the only feature of the software, use third party apps to bridge the gap in the failures of the icedrive team to EVER create a functional sync, and take back the rest of my time. I’m spreading my crappy attitude to the masses on this forum to hopefully help others do the same – keep more of their time and lean into the only part of the program that works as intended, while giving up on any expectations further development of a side of the app that they have continually gaslit users about for 4 solid years. Add to the fact that the team only seems to be a handful of dudes who, I’m guessing might have other jobs, and that they have now spread their resources even more thin with iceVPN, and that they have been aware of these issues for months and not fixed them yet, and… yeah, “abandon all hope” is my best suggestion.
As for your question about freefilesync vs syncback, I don’t know of any significant difference. If syncback does what you need it to do, great. I like FFS but haven’t tried other software either. The main advantage of freefilesync for me is that when I use it, I get to say “FFS!!!” which mirrors exactly how I feel about having to use it to patch up the deficiencies of a paid product.
@tambo - I have to admit my optimism is getting a bit dented as the wait gets longer. I was just trying to give the benefit of the doubt and some time for them to fix things. When I wrote that, I thought the silence could be interpreted to mean that they were focussing on taking all this feedback on board. But now we see the release of IceVPN, which means they were working on that instead.
So now I don’t know. There’s something someone else wrote, on a related thread; the sentiment that we users were acting in good faith by providing feedback (and putting in work to do so), only to be met with a shrug of the shoulders. That’s been going round in my head for a while.
I’m a software developer, myself, so I can sympathise with the workflow and I can imagine an environment of competing priorities and distractions from management, etc. But surely someone of influence in IceDrive has seen this thread by now? I’d have parked IceVPN and fixed this issue first. But that’s me.
Right now I’m getting a bit jaded.
BTW - I also noticed the FFS acronym! I’ll stick with SyncBack for now, as I’m used to it. I haven’t tried it on IceDrive yet, but I’ll set up a manual backup soon and see how it goes.
@tamboI 'd have parked IceVPN and fixed this issue first. But that’s me.
I fully agree I don’t see this as a priority at all wen your overall sync / backup soft is full of bugs…
Sorry to toot my own horn here, but…
Totally called it. Arctic Adaptation: Icedrive’s Response to UK Privacy Laws - #20 by tambo