The New Propagator
First of all, we have completely redesigned The Propagator. It’s the component that is responsible for actually performing all the changes that earlier phases in a sync run have determined to be required. It is vital that the propagator does things in a clever way, and the new design allows just that. The new propagator writes changes to the sync journal as they happen, and does not rewrite the journal after every run. This means that sync runs can be paused or even terminated, and on the next start, the client will pick up where we left it. This is especially important for the initial sync which may take quite a while.
Next, we sped up sync runs significantly. If you are using an up-to-date server version, ownCloud Client 1.5 only requires one instead of three round trips to get a simple file uploaded, since the server can now accept the modification time as a header value. This will especially help with small files.
Another thing this release gets straight is support for remote moves: The old propagator handled them in terms of delete and re-download, which is a bit silly to begin with. Finally, with the new propagator, we can correctly handle moves for what they are, which turns pushing Megabytes of files into a simple mv instruction. In order to detect moves reliably, we now use file IDs next to ETags other meta data, which requires ownCloud 6.0 on the server side.
When you deleted folders, the old propagator would work strongly recursive, meaning a deletion one-by-one. This had several implications, as the non-atomic way of the old approach was problematic as it allowed for unexpected errors to happen. Also every file would be moved to the trash separately (assuming you had the trash app activated), making restore rather painful. The new propagator does away with all this: If you delete one directory, only the directory with all its structures will be moved to trash. As a side effect, this makes the delete operation on the wire much faster.
Handling Error Conditions
There are some situations where syncing a file cannot succeed, for instance when the shared folder on the server cannot be written to. Previously, we would try again and again and again which caused system load.
Now in cases like read-only shared folders we actually know that we will never succeed — until someone changes permissions on the server, that is. So now the client will put files it cannot write to on a black list. Only when the file or one of its parent directories changes, we check again if we are now allowed to write. This should improve traffic and CPU load a lot.
Another issue we addressed was our new handling of files that are on the local ignore list or which contain characters that cannot be replicated to other operating systems (which is an ongoing discussion). Most people were well aware that it would never work, making the (i)-indicator we were showing an annoyance. We also indicated the failure in a log dialog, which turned out to be too well-buried.
In the new release, the sync log has been renamed “Sync Activity” and was placed more prominently as a top level item. It shows all files that have been synced, as well a items that could not be synced at all. The systray icon will not show the (i) icon anymore.
One Account to rule them all
Another major change won’t be visible to you until you look at the source: The Account. It has been introduced as a first step to implement support for multiple accounts in forthcoming versions. For now, it suffices to say that this change has made the internals easier to understand and extend.
Password handling and Signing out
A direct implication is that the client now has a folder-spanning notion of being on- or offline. In addition to that, you can now also sign out. This means your password will be locally discarded. Should the password change or should you have signed out and want to sign back in, you will be queried to enter your password.
This release addresses more than 50 issues (features, enhancements, bugs), so this tour is by no means complete.
We hope you like the new client, and we appreciate your feedback. Please head over to the issue tracker to tell us about bugs or regressions.