Every time odrive updates it creates a new version subfolder in %USERPROFILE%.odrive\bin. The main odriveapp.exe lives here along with the crypto files, MFC dlls, MSVC redistributables, Qt stubs, etc. Using a new folder may well ease the upgrade process, but it raises a problem for users with restrictive firewall policies. The program with outgoing connections is odriveapp.exe. If a firewall is set to block by default, a newly updated odrive install will not communicate until firewall rules are altered. Upgrades happen at random times, so any firewall alerts may well be missed.
Some background: We operate worldwide, including in countries that, shall we say, are hacker havens. Any laptops operating in these regions absolutely needs block-by-default firewall rules. We standardized on this approach for almost all laptops and most workstations as a security policy.
Were the main odriveapp.exe file always located in %USERPROFILE%.odrive\bin rather than a version-specific subfolder, it could be whitelisted in firewall rules. All ancillary files could live in the version folder.
I came here to post the exact same request but for the OS X version too. I use Little Snitch as my firewall and odrive is approved by the path to the executable binary. On OS X, that location is /Users/[USERNAME]/.odrive/bin/[VERSION]/odriveapp.app/Contents/MacOS/odrive.app
With each update, the odrive app is blocked and needs to be approved again because the VERSION number part of the path changes.
As a note, this changed in early January to using the version numbering. Before that, the path was .../bin/current/odriveapp... and the updates were installed into the same current path.
Could you please go back to the previous method with the current path?
@Tony and @Jeff_Lin: Sorry to bump a request but any chance of getting this change added soon?
With odrive being updated on almost a daily basis (which is awesome BTW), this kills it from syncing on my remote systems until I log in and approve it.
Another unrelated thing, I think there was a thread about this but I can’t seem to find it:
Why are you still creating separate folders for each version of odrive when it updates? Beside the firewall stuff which was mentioned, the desktop.ini file of the odrive folder is not being updated, and the icon is lost. Some other practical stuff too, e.g. I make the odrive icon always visible on the taskbar, but when it updates it gets hidden again, probably because of the path.
Hi folks,
Don’t worry, I hear you. The current method removed some complications with upgrades, but the reasons for static locations are good ones. This needs more review internally.
@Tony, any progress on this issue? It is still a major problem for those running firewalls.
If you haven’t looked into other methods of upgrades, please take a look at the Sparkle Project. It is a very popular framework used to upgrade installed and running applications.
Even if you don’t use Sparkle itself, it is open source so you can see the code in their GitHub repo. Perhaps it will give you some ideas on how you can handle odrive upgrades without using static version number paths.
Hi @Smudge,
It was reviewed and some options were discussed, but it is still an item on our backlog.
The request is understood and valid. Unfortunately it is non-trivial (and introduces a fair amount of risk) to change the auto-update mechanism, which currently works very well, despite this particular caveat.
I agree; the existing update mechanism works … as long as it occurs when the computer in question is actively being used. Otherwise the outcome depends on firewall configuration. If a machine uses a “trust any outbound traffic” policy, odrive updates successfully. More restrictive firewall policies result either in the updated odrive executable being blocked silently or a popup asking what to do. Again, if the update occurs when no one is actively watching, odrive loses ability to communicate.
This has been an all-too-common occurrence for us. Odrive stops syncing until firewall rules are updated.
A possible solution would be to have a limited number of static locations where the odrive executable could reside. These would be rotated with each update and the executable could be whitelisted in each place.
For the immediate term, do you think it would be viable to setup a scheduled task that updates the odrive firewall policy at frequent intervals to the new path?
@Tony: That depends on the environment odrive is used in. If we’re talking single users running Windows firewall, then a scheduled task can work. My suspicion is that this could handle a significant portion of odrive free users.
Business environments get more complicated. Many of use use centrally managed environments for security options. We use a third party firewall, others don’t but still push FW settings through Group Policy. I’m looking for a means of managing odrive updates in something than than innumerable one-off hacks.
@Ethan
Yes, I was wondering more for your specific environment. You mentioned the system users taking action, themselves, to adjust the firewall rules on an update, as opposed to requiring administrative action, which led me to think that something simple like this could help those users.
As you said, things can get more complex with some business environments (although they can also present more elegant solutions, too, depending on how things are managed). Enterprise environments can get even more sticky, with the admins wanting to prevent automatic updates, completely
We have both types of installations. A few users have admin privileges to modify and/or customize firewall environments on selected systems. These systems are used to create the templates the majority of our employees use.
