Overwriting is underrated

Improvements for all users:

• In some situations, when moving a file or folder and overwriting an existing
  document, the local file system can fire a move event without firing a
  deletion event for the document that's being overwritten. We were very
  conservative in the way to we treat changes that could erase content so we
  would generate a conflict for those moves.
  Now that we have file versioning on the Cozy, we feel comfortable accepting
  those changes and will thus delete the overwritten document but will keep its
  existing references (e.g. photos album, bills…) and add them to the document
  being moved.
• We've found out that the synchronization process could be started more than
  once. Although this should have no effect (i.e. one start replacing the
  previous one) we've made sure we only start the process once. This should
  avoid wasting some resources in an extraneous start.
• Following some feedback on the app updater window which could give the feeling
  that the update was not going to complete, we've made a small redesign of this
  window, replacing the indeterminate progress bar with a spinner and adding
  emphasizing the text asking you to be patient until the download is complete.

Improvements for Windows and macOS users:

• To avoid synchronizing temporary documents generated by some software when
  saving a new version of a document, we maintain a list of file name patterns
  that should not be synchronized. We had some patterns for the Microsoft Office
  suite files but we did not account for temporary files generated for all the
  file types those can open like Open Documents.
  We've widened the pattern used to match those files those that all temporary
  files created by the MS Office software should be matched and thus not be
  synchronized.

Improvements for Linux and Windows users:

• During the initial scan of your local synchronization folder, we emit deletion
  events when we detect a know document is not present anymore (i.e. we assume
  you've deleted it while the client was not running). The order in which we
  emit those events is important because it will be the order in which those
  actions will be synchronized and if we try to synchronize the deletion of a
  directory before the deletion of its content, the folder will end up in your
  Cozy trash bin instead of being completely removed.
  This is not a big issue but to avoid any confusion as to why we'd put those
  files and directories in your trash, we've modified our algorithm to emit
  events for children of deleted directories before the event for the directory
  itself.

Improvements for Windows users:

• We found that in some situations, the order in which local file system events
  are received by our local changes watcher was not as expected, resulting in
  some movements not being detected as such. We would then delete the source
  documents and recreate them at the destination, losing in the process some
  important metadata like sharings.
  Our Windows movement detector is now more resilient to the order of events and
  should detect all movements as such.
• We've got reports from users experiencing app crashes. In at least some of
  those cases, the anti-virus seems to be involved.
  We've implemented some mitigations as found in the Electron documentation and
  hope to see those issues resolved.

See also known issues.

Happy syncing!