Release v3.21.0-beta.3 (#1883)

Improvements for all users:

• The client would not detect the correct mime type for .cozy-note files when
  detected on the local filesystem. This would change the saved mime type of
  notes moved on the local filesystem and not show the correct icon in the
  Recent changes list in our main window.
  We've switched to a custom mime detector for those files to detect our custom
  mime type.
• Since propagating a local file update to a remote Cozy Note would break this
  note (i.e. it would not be detected as such and we would lose its actual
  content while still keeping its markdown export within the associated Cozy
  file), we've decided to prevent all local note updates to be propagated to the
  remote Cozy.
• In order to still synchronize your local updates to notes with your remote
  Cozy, we're now using the conflict mechanism to rename the original note on
  the remote Cozy before upload your new content to the appropriate location.
  This way, you have both your updated content and the original note that can
  still be edited within the Cozy Notes application.
• We've found that when renaming a folder while another folder within the same
  parent starts with the renamed folder's original name (e.g. renaming cozy to
  cozy cloud while you have cozy company in the same parent) would lead to
  the incorrect movement of the content of the other folder (i.e. the content of
  cozy compnany in our example).
  We've fixed the algorithm that lists the content of a folder so that it looks
  only within the exact given location and not similar locations.
• In some situations, locally creating a folder within a moved or renamed parent
  could lead to the creation of a new parent folder on the remote Cozy at the
  target location, thus making the parent movement impossible since a document
  would already exist at the target location. This situation was caused by some
  logic we implemented to help create complex hierarchies in any order. We would
  create a missing parent folder when creating a new folder on the remote Cozy.
  We've now stopped doing this and will not synchronize the creation of a folder
  if its parent does not exist. In case the parent location would be created
  later by the client (e.g. when propagating the parent movement), the new
  folder will eventually be synchronized.

Improvements for Windows users:

• To emphasize the fact that Cozy Notes should not be edited on your local
  filesystem we mark the local note files as read-only. This does not prevent us
  from overwriting them with new remote updates on Linux and macOS but it does
  on Windows in some cases. In those cases, the local file content does not
  reflect the remote content anymore and it can even lead to the remote Note
  being broken after a Desktop client restart.
  We're now adding write permissions the local file when we want to update it
  with new content coming from the remote Cozy and switch it back to a read-only
  mode afterwards.

See also known issues.

Happy syncing!

Release v3.21.0-beta.2 (#1868)

Improvements for all users:

• We missed a spot when introducing the deletion marker in the previous beta
  release which could lead to remote restorations being handled as movements if
  the previous deletion was merged into the local PouchDB database but not
  propagated to the local filesystem.
  We haven't identified visible issues coming from this yet though.

See also known issues.

Happy syncing!

Release v3.21.0-beta.1 (#1866)

Improvements for all users:

• Moving a document to an ignored location (see
  https://github.com/cozy-labs/cozy-desktop/blob/master/core/config/.cozyignore
  and your local .cozyignore rules file) after another move would result in
  the first move being propagated to the remote Cozy and the document being
  desynchronized after that.
  From now on, the second move to the ignored location will cancel the first
  move and the client will correctly propagate a deletion to the remote Cozy.
• Deleting a file on your Cozy while moving it on your local filesystem with
  your client stopped would lead to the desynchronisation of the file. It would
  be deleted on your Cozy but would still exist on your local filesystem and all
  later modifications would not be propagated.
  We're now refusing the deletion because we believe the movement indicates a
  desire to keep the file and it seems easier for the user to understand and fix
  the situation if that was not the expected behavior. The file move will then
  be propagated to the remote Cozy and kept in sync.
• In some situations we can detect changes made on your remote Cozy on documents
  of which we haven't yet received the parent folders. We can't process orphaned
  documents so we require the parents of all documents before we allow
  processing those and if we don't have them, we'll issue an error that results
  in the "Synchronization incomplete" status message, literally blocking the
  synchronization process.
  We believe that most of those issues could resolve themselves by merely
  refusing the orphan change and synchronizing the other changes so we've
  decided not to block the synchronization process anymore when we encounter
  orphan changes.
• We detected that the remote watcher whose role is to detect, fetch and analyze
  changes coming from your remote Cozy could fail without the synchronization
  process stopping and alerting you. This means that in such cases, the changes
  made on your local filesystem would still be detected and potentially
  propagated to your remote Cozy but the changes made remotely would not be
  applied locally until a client restart.
  We've refactored the life-cycle management of the whole synchronization
  process and the remote watcher and we made sure that errors coming from the
  remote watcher are caught by the synchronization process which will in turn
  alert you and stop itself and both local and remote watchers.

See also known issues.

Happy syncing!

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!

Release v3.20.0-beta.6 (#1860)

Improvements for all users:

• The updater window was smaller than anticipated when bringing the window
  redesign to life so all the content would not fit inside, especially with
  French text. The spinner has been shrinked down to leave more room for the
  text and the French translation modified so that the first sentence would fit
  in one line.

See also known issues.

Happy syncing!

Release v3.20.0-beta.5 (#1858)

Nothing to see here. This release let's us test the previous redesign of the updater window.

Release v3.20.0-beta.4 (#1857)

Improvements for all users:

• 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.

See also known issues.

Happy syncing!

Release v3.20.0-beta.3 (#1854)

Improvements for all users:

• This release fixes a small typo that prevented the overwriting moves to
  function properly.

See also known issues.

Happy syncing!

Release v3.20.0-beta.2 (#1852)

Improvements for all users:

• 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.
• 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.

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 enlarged 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 Windows users:

• 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!

Release v3.20.0-beta.1 (#1833)

Improvements for all users:

• In an attempt to avoid losing your data, we were very cautious when we
  detected movements that would overwrite documents we were aware of and would
  create a conflict document instead. There are a number of situations where
  this is not ideal because you actually wanted to overwrite this destination
  document (e.g. saving a file from an office software which uses a temporary
  file, overwriting a directory on purpose).
  With all the safeties we have in place today (i.e. trash bins on both your
  computer and your Cozy plus file versioning on your Cozy) we decided to accept
  more overwriting movements when we did not detect un-synchronized changes that
  would be overwritten by this. This should mean a lot less conflicts when using
  Microsoft Office softwares and the possibility to overwrite both files and
  directories.

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.

See also known issues.

Happy syncing!