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.
So we’re out here figuring out ways to make IceDrive work the way it should, with not a peep from the IceDrive team.
Absolutely right. Y’know what, F it. I’m tired of this situation where we all get frustrated at the obvious regressions and lack of transparency, talk amongst ourselves on these forums, and the people who can actually do something about it give placating but noncommital answers at best. Let’s use electronic accountability to make it harder for them to ignore, or more obvious if they do. @Chris@Tom@JimmyB - where we at on this?
“We hear you, I will forward this on to our development team to consider.”
was on Oct 1. That was almost 2 months ago. What was communicated to the development team, how has their “consideration” gone, and what was the outcome or proposed solution, if any? What is the timeline to a functional sync, given the fact that the team has apparently been aware of this issue since the inception of v3 on September 3rd, and likely before? Three months is a long time for a glaring flaw in a sync feature for a paid product/service that advertises sync capabilities. And since you’re releasing new products, I would assume that everything in your core offering is already on the up and up, or being worked on around-the-clock to ensure that it gets to a functional state post-haste. Please help restore my faith.
@FrankS you beat me to it
seeing your assistance to another user here asking for some help on syncing with 2.75 I was wondering how long it still may take to get a robuster update in 3.23 as has been a while
For the past few weeks, I haven’t really thought about computer stuff and just kept Icedrive running in the background, being careful not to shut it down. Yesterday I ran a comparison with FreeFileSync, and found several problems:
4 new files were not uploaded to the cloud.
1 edited file was not updated in the cloud.
1 deleted folder (with 3 files in it) was not removed from the cloud (even though ‘deletion policy remote’ is set to ‘delete’).
35 moved files were correctly moved in the cloud, but also remained in their original location (i.e. they were duplicated in the cloud).
So it seems to me that Icedrive is not working properly even when running in the background. Can anyone confirm this?
@Guido - confirmed. Very similar results to yours.
I’ve actually deleted all my sync pairs and am now experimenting with FreeFileSync. I also tried out Syncback, but abandoned that effort after it wanted to transfer too many files at once and Icedrive crashed!
Now I’m waiting for the backlog to transfer before looking at FreeFileSync again.
It’s all a bit of a mess over here.
But it is Black Friday… I’ll just leave that comment there. Make of it what you will.
I see what you mean. Actually, I had almost decided to look for a competitor, until I realized that the combination of Icedrive’s mounted drive and FreeFileSync is not just a patch, but is in fact gold. Buggy as Icedrive’s syncpairs may be, the fact that FreeFileSync can check and correct everything gives me huge peace of mind. After reading this comment by @Abe, I am not sure competitors can provide the same level of assurance…
@Guido I’ll show my cards. I actually did buy a deal with a competitor.
So right now, I’m actually comparing two side by side. There’s a school of thought I stumbled across that says you don’t actually need the baked-in encryption. You can achieve the same effect with Cryptomator and a regular mounted cloud drive. This nullifies the selling point of zero-knowledge encryption.
And that, in turn, means, for Icedrive to be truly useful is to get those sync pairs working properly, because for me, right now, the competition is between Icedrive syncing reliably and Cryptomator + competitor.
@Guido@lawgiver_ai Just want to add my two cents here. I use my own encryption before uploading to ANY cloud. And I use FreeFileSync to sync files at home. The problem with ID occurs during upload and/or (re-)download. If the file being uploaded to ID cloud OR being downloaded from ID cloud becomes corrupted, there’s nothing for FreeFileSync to find when it matters–cloud file fidelity. FreeFileSync doesn’t compare what’s in ID’s cloud with what we expect to upload. Maybe that works differently with a locally synced folder, but I don’t have luck with sync pairs. (I used FIVE privacy clouds and all have sync folders constantly getting screwed up. If it matters, Sync.com is most reliable and has a Linux work-around, but is based in Canada, a Five-Eyes country. Buyer Beware.). Amazon Cloud & Microsoft (cloud) employ a cloud checksum (from what I’ve read of their services) so customers can feel confident what’s in these companies’ clouds is what customers expect. But that is probably not compatible with zero-knowledge E2E-encryption.
Over the years, I’ve found using my own encryption before uploading to clouds complicates syncs tremendously. And no privacy-friendly cloud offers a reliable way to double-check what was uploaded to the cloud matches my local copy. Could do Rclone, but I don’t have the time to set that up. I wanted an out-of-the-box solution. About half of the files I download from ID’s cloud over about 1 GB either never arrive on iOS or are corrupted on Windows or Mac OS despite high-speed, stable internet. I want to love ID. But I just can’t trust ID with my documents. The only way ID works for me is to manually upload tiny files–under 1GB or so. Not bashing the company. I support ID because privacy is super-important to me. But corrupt files are useless to me and a massive waste of time since I don’t know WHICH files in the cloud are corrupt. Which is why now I rely on my own home backups only.
@lawgiver_ai That sounds interesting. Let us know about your experiences with Cryptomator! I am especially curious about how this works out in everyday life. I often need to move files around in the file explorer and I cannot afford for my backup system to slow me down.
@Abe Thanks for weighing in. I hadn’t given much thought to file corruption yet. Another complication… Perhaps one should have two remote backups to account for corrupted files in either one of them (and more than two if you deal with large files).
This has been really helpful. I’ve had endless issues with Icedrive syncing and not trusting results since I bought their plan several years ago. Can you clarify: you use FFS to ‘sync’ to the mounted Icedrive?
And you (so far, based on your experience) trust the mounted Icedrive to upload reliably?
@Guido - to answer your Cryptomator question. I’ve set it up like this:
Mounted drive to cloud folder (X:)
Cryptomator sets up another mounted drive (Z:)
But Z: is actually a “decrypted view” of X:\MyFolder
I copy files into Z:
Cryptomator encrypts before writing to Z: (= X:\MyFolder)
Cloud software uploads X:\MyFolder to remote and knows nothing of Z:
What do I see:
If I open Z: I see all my files as I copied them, whether they’re actually uploaded or not.
If I open X:\MyFolder, I see a load of incomprehensible stuff.
If I open MyFolder on the cloud web interface, I see the same incomprehensible stuff.
It seems the copy stage can be done any way you like. I’ve tested out FFS and Syncback and both are fine as far as I can tell. The copying to Z: does seem to take time, as I’d expect, since that’s when the encryption takes place. The upload to the cloud just runs at my network speed and seems perfectly fine.
If you’re wondering about disk usage - it seems to depend on what’s been uploaded to the cloud. If I overwhelm Z: with a ton of files, I see it in my disk usage. But that slowly claws back down as the encrypted files are uploaded.
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?
Can anyone confirm this?
Actually, I had almost decided to look for a competitor, until I realized that the combination of Icedrive’s mounted drive and FreeFileSync is not just a patch, but is in fact gold. Buggy as Icedrive’s syncpairs may be, the fact that FreeFileSync can check and correct everything gives me huge peace of mind. After reading 
Perhaps one should have two remote backups to account for corrupted files in either one of them (and more than two if you deal with large files).
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?