OmniPresence for Mac 1.3

March 4, 2015

Requires OS X 10.10

OmniPresence v1.3 improves sync performance and error handling. This version requires OS X Yosemite (10.10) or later.

  • Performance — Improved use of previous redirects during WebDAV operations to avoid extra round trips with the server.
  • Login Item — Fixed a problem where the “Open at Login” support would attempt to launch the copy of OmniPresence in the trash after a software update.
  • Error Handling — Fixed a data loss bug that could occur rarely if the sandboxing system starts denying access to portions of your synchronized folder.
  • Error Handling — Fixed a problem where the menu item would sometimes not show an error indicator when one of the synchronized folders couldn’t be synchronized.
  • Setup — OmniPresence will no longer let you put one synchronized folder inside another.
  • Last Sync — The “Last Sync” date should no longer say “None” when launched.
  • Server Clean-Up — OmniPresence now cleans up old versions of files on the server in some cases it didn’t before.

OmniPresence for Mac 1.2

October 29, 2014

Requires OS X 10.9

OmniPresence 1.2 for Mac has been updated to work better on Yosemite, and also improves the handling of conflicting edits across devices.

New:

  • Yosemite interface — Updated the app interface and the icons for synced folders to look more at home on Yosemite.
  • Yosemite Dark Mode — Updated the menu bar icon to display properly when using Yosemite’s Dark Mode, and updated the main window’s appearance to be more usable in dark mode.

Updated:

  • Auto-Sync — Made auto-syncing happen more reliably when changes are synced to the same cloud location from another device on the same network.

Fixed:

  • Error Handling — If too many attempts are made to transfer a file, OmniPresence will now pause syncing and offer to report the error.
  • Conflicts — OmniPresence no longer permanently renames files when there is a conflict. Instead, each client locally renames the files and doesn’t send those renames to the server (which could cause extra conflicts in heavy usage cases). If you rename one of the files that is in conflict, that file gets renamed on the server as well and other clients will see that name. If there is only one version of a file left in conflict (maybe you deleted the other conflicting versions or renamed them to something else), OmniPresence will rename it back to the original user-specified name.
  • Spurious conflicts — Fixed an issue where OmniPresence would treat an interrupted network connection as a failure, and if it turns out the operation actually succeeded it would treat that as a conflict (since it didn’t think it made that change itself). This should make syncing much more reliable when syncing over slow (or distant) networks.
  • Simultaneous setup — OmniPresence conformance tests will no longer fail when more than one device is performing those tests at the same time.
  • Open at Login — Fixed some cases where the “Open at Login” menu item wouldn’t work properly.
  • Crash — Fixed a crash that could happen when updating the settings for a cloud location.

OmniPresence for Mac 1.1

November 12, 2013

Server Clean-Up — OmniPresence will now correctly clean up temporary files left on the server during previous syncs.

App Icon — OmniPresence has a new application icon.

Many Smaller Fixes and Improvements

OmniPresence for Mac 1.0.2

August 1, 2013

Encryption — When OmniPresence is configured to use an encrypted https:// connection to a server, it will now ignore any location headers from that server that tell it to switch to unencrypted http://. Our assumption is that your configuration choice indicates that you want all sync operations to be encrypted, and that any servers which redirect to unencrypted http:// locations for these resources are simply misconfigured.

OmniPresence for Mac 1.0.1

June 14, 2013

Hopefully Fixed Our Most Frequent Crash — OmniPresence has been remarkably stable, but we’ve seen a few reports of it crashing in the background when it tries to access the keychain to authenticate a sync operation with the server. We haven’t been able to reproduce this on demand, but we’re guessing that some of the operating system’s keychain code might not be thread-safe. We’ve rearranged our code to look up credentials from the main thread to see if that fixes the problem.