Release v3.22.0-beta.5 (#1933)

Improvements for all users:

• The list of recently synchronized files could contain folder items when their
  parent was moved or renamed.
  We're now making sure only file items will be displayed in this list until we
  officially support folder items.
• We increased the number of file types that will be displayed with a specific
  icon to help you check more easily which elements were synchronized. This
  includes 2 new icons for links (i.e. .url files) and contacts (i.e. .vcf
  files).

See also known issues.

Happy syncing!

Release v3.22.0-beta.4 (#1930)

Improvements for all users:

• The list of recently synchronized files could be persisted multiple times
  concurrently, leading to malformed JSON content which could not be loaded back
  into the client's GUI during the next start.
  We're now making sure each write is done sequentially so that the list is
  always saved as valid JSON.

See also known issues.

Happy syncing!

Release v3.22.0-beta.3 (#1928)

Improvements for all users:

• The list of recently synchronized files and the linked Cozy information would
  sometimes not be displayed after a client restart, especially on Windows.
  The data was correctly persisted though and we've made sure it is correctly
  loaded and displayed now.

See also known issues.

Happy syncing!

Release v3.22.0-beta.2 (#1924)

Improvements for all users:

• Files with remote creation or modification dates in a timezone other than UTC
  would raise an error in the remote watcher when converting them into PouchDB
  records.
  We're now rounding those dates with a timezone agnostic method and those
  errors should not happen anymore.

See also known issues.

Happy syncing!

Release v3.22.0-beta.1 (#1921)

Improvements for all users:

• As a multi-device platform, Cozy Cloud tries to keep the modification dates of
  documents in sync across all your devices (i.e. Drive Web, Drive Mobile,
  Cozy Desktop, other people's Cozies…). When modifications happen on the Cozy
  itself, the modification date is set by the server. On the other hand, when
  the modification is made on on your computer, we get the date from your
  filesystem. We were using the most recent date between the content
  modification date and the metadata modification date but we think the content
  modification date is the most important and that it should not be affected by
  movements, renamings, permission changes, etc.
  For this reason, from now on we will only use the content modification date on
  Cozy Desktop.
• When you start your Cozy Desktop client, we scan the whole synchronization
  folder on your computer to detect document additions, modifications,
  movements… The file modification detection is done in 2 steps to avoid time
  consuming computation:
  1. we compare the modification date fetched from your filesystem with the one
     we last saved in our database
  2. if and only if they differ, we compute the file's checksum to compare it
     with the one saved in the database
     Our modification date was not completely reliable, especially on Windows and
     Linux so we were computing a lot of checksums for files that were not modified
     while the client was stopped.
     We're now using the local file state which holds a reliable content
     modification date and we should avoid a lot of checksum computations thus
     saving you a lot of time during a client start and a lot of CPU resources.

Improvements for Windows and macOS users:

• A file name case change on the remote Cozy followed by a remote content update
  could lead in some situations to the local file being trashed on the computer.
  On macOS this could also happen if the renaming was simply a normalization
  change or there was a normalization difference in the name of one of its
  ancestors.
  We've changed the way we handle the conjunction of those 2 changes to make
  sure case and normalization changes don't affect them. The file should now be
  properly moved and updated on the local filesystem.

Improvements for Windows users:

• Some Windows software save modifications made on a file by moving this file to
  a backup location before writing the new version in its stead. The events
  received by Cozy Desktop in this situation were not correctly interpreted as
  we did not expect it and the client would trash the file on the remote Cozy
  before uploading the new version. If the client were to be stopped before the
  new version was uploaded, the file could stay trashed until the client was
  started again.
  We're now expecting this suite of events to happen and are applying a specific
  behavior to transform them into a file update that will be correctly
  propagated to the remote Cozy as one change thus avoiding situations where the
  file is trashed.
• The local file state introduced in the previous release was not fully
  populated on Windows when propagating the addition of a file from the Cozy to
  the local filesystem due to a bug.
  While it should have been without consequences, the bug was fixed and the
  features requiring this local state to be populated (e.g. limiting the number
  of file checksum computations during a client start) should be fully
  functional.

Improvements for macOS users:

• A lot of improvements around the support of NFD/NFC UTF-8 normalizations for
  document paths, especially when they differ between the remote Cozy and the
  local filesystem.
  You shouldn't see synchronization errors due to the renaming, movement,
  addition, modification of files and folders with accented names.

See also known issues.

Happy syncing!

One small step for Cozy Notes...

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.
• 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.
• Remote changes resulting in an MergeMissingParentError do not block the
  synchronization process since v3.21.0-beta.1 but the changes from the affected
  batch and the ones coming after will be fetched over and over again until the
  errors are resolved, which might never come.
  We've identified a few sources of those errors that should be fixed really
  soon and believe we should not encounter solvable missing parent issues
  anymore so we've decided to mark them as processed anyway and rely on the next
  changes to resolve those missing parents issues.
• We added a migration to force a refetch of all remote Cozy Notes in order to
  avoid as many dispensable conflicts as we can during the first reboot after
  this release installation.
• We made sure a Cozy Note is still identified as such after saving changes like
  an update on the remote Cozy. This will ensure they will stay protected from
  local updates afterwards.
• Until now the authentication of your Cozy during the initial connection of the
  client would always be done by our own remote application. We're adding the
  possibility for partners to offer their users to connect via their own SSO
  portal so we now run the connection flow in a dedicated sandbox.
  This has two advantages when an SSO portal is involved:
  1. the portal code is run in a browser like environment with no alterations so
     it should work out of the box
  2. the portal code is isolated from the rest of our application adding another
     layer of security preventing malicious code on the portal itself to access
     your computer
• We made sure the application of the move and update of a file on the local
  filesystem does not trigger invalid changes that would be propagated to the
  remote Cozy.
• We discovered timing issues during the propagation of remote file changes to
  the local filesystem. These can result in invalid metadata being sent to the
  remote Cozy after propagating a grouped content update and file renaming. In
  case the file was in a shared directory, the metadata change would in turn be
  propagated via the sharing to other Cozies and we can end up with a
  completely desynchronized file and conflicts.
  To prevent these invalid metadata from being propagated to the remote Cozy, we
  introduced a new way to store and compare local file states. This also helps
  us detect during a client restart when a remote file modification was fetched
  but not completly propagated to the file system and avoid creating a conflict.

Improvements for Windows users:

• To emphasize the fact that Cozy Notes should not be edited on your local
  filesystem we were marking the local note files as read-only. This was not
  preventing us from overwriting them with new remote updates on Linux and
  macOS but it was on Windows in some cases. When this would happen, the local
  file content would not reflect the remote content anymore and it could even
  lead to the remote Note being broken after a Desktop client restart.
  Since we've now introduced a conflict mechanism to protect Cozy Notes from
  local modifications, we can remove the read-only permission and remote updates
  will be propagated to the local filesystem on all platforms.

See also known issues.

Happy syncing!

Release v3.21.0-beta.10 (#1906)

Improvements for all users:

• We introduced a new way to store and compare local file states. This is the
  first step to solve different problems. We're solving a first issue by
  preventing fake metadata (i.e. size and content checksum) from being
  propagated to the remote Cozy when a Cozy Note is both renamed and modified
  during a very short period.

See also known issues.

Happy syncing!

Release v3.21.0-beta.9 (#1903)

Improvements for all users:

• We made sure a Cozy Note is still identified as such after saving changes like
  an update on the remote Cozy. This will ensure they will stay protected from
  local updates afterwards.

Improvements for Windows users:

• We made sure the application of the move and update of a file on the local
  filesystem does not trigger invalid changes that would be propagated to the
  remote Cozy.

See also known issues.

Happy syncing!

Release v3.21.0-beta.8 (#1899)

Improvements for all users:

• We added a migration to force a refetch of all remote Cozy Notes in order to
  avoid as many dispensable conflicts as we can during the first reboot after
  this release installation.

See also known issues.

Happy syncing!

Release v3.21.0-beta.7 (#1894)

Improvements for all users:

• Until now the connection to your Cozy would always go through our own
  infrastructure only. We're adding the possibility for partners to offer their
  users to connect via their own SSO portal so we now run the connection flow in
  a dedicated sandbox.
  This has two advantages when an SSO portal is involved:
  1. the portal code is run in a browser like environment with no alterations so
     it should work out of the box
  2. the portal code is isolated from the rest of our application adding another
     layer of security preventing malicious code on the portal itself to access
     your computer

See also known issues.

Happy syncing!