When user wants to limit the bandwidth, he does not care about speed
anymore. And parallelism on slow network might cause problems.
For issue #3382
Will also help for #3095
(cherry picked from commit b20f29f22797367c7aa92bd74389c99b10c852a4)
csync_vio_local_unix.c:109:7: warning: ignoring return value of function declared with
warn_unused_result attribute [-Wunused-result]
asprintf(&file_stat->original_name, "%s/%s", handle->path, dirent->d_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This should allow for the case when a user has set the limit to 0 and a new empty folder appears on the server. The folder will have size 0 (no files in it). Doing the >= test here will mean that the user will be prompted about the new folder, which I think is the behaviour they would expect.
The side-effect of this change is that if the user has a limit of, for example, 10,000,000 and a new folder comes along with exactly 10,000,000 of content then they will now be prompted about it. Before the change such a new folder would have been auto-synced without prompting the user. I do not think this is a big deal - I cannot believe that users will be counting exact bytes for this limit, they are just setting a rough number of MB at the UI.
Should fix https://github.com/owncloud/client/issues/3542
Now that the client is pushing all changes of state, we don't need
to track the requested URLs anymore and risk that the way that we
reseted that list could leave a few entries in Finder's cache outdated.
We can remove the same code from other platforms in a later release,
a bit earlier than a week before beta1.
This fixes a few issues with the new FinderSync integration on OSX which
can't easily clear its status cache when receiving an UPDATE_VIEW message
except by unregistering the folder, but which causes flickering.
This fix should also make the regeneration of the cache unnecessary on other
platforms through possibly expensive RETRIEVE_FILE_STATUS commands.
