eDrive

What's new in eDrive 0.3.0:

• Changed the logic related to starting up Synchronisers managed by eDrive. Previously if eDrive failed to start a Synchroniser it would queue it for retry in X seconds (default 5 mins) see -Dedrive.retry.seconds defined below for Version 0.2.0 point 3 and point 4 for how this worked. However, one use case popped up after this change where if eDrive is configured as a service on Windows it's possible eDrive tries to start before the ethernet service is running, and if you have no saved serialised file, it would consider this a new Synchroniser, report the issue in the log, and would NOT re-queue for a later re-try. To avoid this, eDrive now re-queues ALL synchronisers on the first failure and only after the next re-try fails would it apply the is-new is-existing logic. This provides for more than enough time to elapse for the dependent windows services to become available.
• Changed the mime detection logic used when creating new content in the Repository. The mime detection was previously based on file extensions, but in Linux environments there are many files with no extensions and these would all result in having the mime type application/octet-stream. eDrive now first uses the Java 7 Files.probeContentType(...) method which defers to specific platform implementations to identify the content type. Only if this is unable to determine the content type will it fall back to the previous method. A side effect of this is that people may change or remove the file extensions of files to be created in the Repository and eDrive will now mostly get it correct. For example: Changing my-image.jpg to my-image.gif and synchronising that to the Repository will result in the correct mime type image/jpg being used instead of image/gif as would have previously happened.