We can do that because the only changes that were in master but not in 2.3 were the
translations change and documentation change, and the support for the 'M' permission
which we want in 2.3.
We now delete subjobs as their propagation is complete. This allows us
to also release the item by making sure that nothing else is holding a
reference to it.
Remove the stored SyncFileItemVector from SyncEngine and SyncResult
and instead gather the needed info progressively as each itemCompleted
signal is emitted.
This frees some holes on the heap as propagation goes, allowing many
memory allocations without the need of requesting more virtual memory
from the OS, preventing the memory usage from increasingly growing.
Previously if you paused/unpaused a folder for a disconnected account
they would prepare to sync and thus display the 'Waiting...' text. With
this change, folders that can't possibly sync don't show text like
this.
When account connectivity changes, all unpaused folders will be
scheduled anyway.
Otherwise it might happen that the model is inconsistant and this can
lead to crash in the worst case.
(For example, if there was a "fetching" label, and we hide it because it
was a 404. In this case, we would not call begin/endRemoveRows, so the
view could still call the model with an index of row 0, that used to be
for the label, but now correspond to the first element of _subs. And
because _subs is empty, this could lead to crashes)
We are going to change the webdav path depending on the capabilities.
But the SyncEngine and csync might have been created before the capabilities
are retrieved.
The main raison why we gave the path to the sync engine was to pass it to csync.
But the thing is that csync don't need anymore this url as everything is done by the
discovery classes in libsync that use the network jobs that use the account for the urls.
So csync do not need the remote URI.
shortenFilename in folderstatusmodel.cpp was useless because the string is the
_file of a SyncFileItem which is the relative file name, that name never
starts with owncloud://.
All the csync test creates the folder because csync use to check if the folder
exists. But we don't need to do that anymore
Instead of using the regular selective-sync UI (where it's unclear what
the "Cancel" button would even mean in this context), provide a
different set of buttons that allow the user to quickly synchronize
all pending big folders, none of them, or perform manual changes
as usual.
I got into a situation where the model would endlessly request the directory
contents from the server because we did not notice yet that the server
is actually in maintenance mode while we were expanding the tree view when
changing the tab to the account or when just expanding it by clicking.
* Remove duplicate remote path
* Use thin progress bar
* Move bandwidth and file info to tooltip
* Shorten overall progress message
This also fixes#4562 by making the layout not dependent on the
width of the displayed text.
* Ensure every time a file becomes a directory or the other way around
the item is flagged as INSTRUCTION_TYPE_CHANGE.
* Delete the badly-typed entity if necessary in the propagation jobs.
This use the previous code by resetting the progress to hide
the progress back and then return errors in the FolderErrorMsg
data role of the folder model.
This also remove the unused FolderRemotePath role, remove FolderStatus
in favor of invalidating all roles in dataChanged and make sure
that the SyncRunning role is transfered properly from the SyncResult
to show the warning icon during sync.
It's just a feature that was not there in 2.0
It means that removed folder stay on the undecided list if it is removed
from the server until the user press apply in the selective sync widget.
Not a very bad bug anyway.
If a folder was paused while being the next item in the scheduling
queue, the whole scheduling could get stuck.
This also fixes the progress information of paused folders possibly
getting stuck.
Regressed since d610693af1. The problem
is that the _size vector contains the pathToRemove and that it was removed
before.
Reorganize a bit the code so there is only one loop that has still all the
information.
fixes the unicode issue #3753
I don't know much CPP and Qt but after some google research I found this http://wiki.qt.io/Strings_and_encodings_in_Qt
it does mention trUtf8() that has done the trick for me on Linux with Gnome 3.16.
Haven't tested it on other systems
Christian Kamm