If there is a any none files, we do not show the dialog saying that all
files have been removed. If a directory contiains ignored files, we still
want to show this message box even if the directory will not be deleted
Progress estimation is usually based on transfer speed. That makes no
sense when we're doing operations like deletes, that need very little
data transfer but nevertheless take a long time.
This hack attempts to detect this case better and switches to a
different estimate.
We should rewrite this to maintain and update estimates for the
transfer speed, per-file overhead and chunk-assembly overhead each
time an item finishes. Then we could provide more consistent progress
estimates without ad-hoc fixes like this one.
Also, there's an issue where resuming a partial download will lead
to exaggerated transfer speed estimates.
Introduce a global ExcludedFiles instance to avoid loading the global
exclude lists several times.
One could still add per-folder exclude lists by checking these after
the global ones.
Now that fetchFromKeychain is solely called from AccountState::slotInvalidCredentials
and that this one already protects the fetch call using _waitingForNewCredentials,
we can remove that extra check.
This moves the responsibility of asking the user or not for
credentials from the Credentials classes back to the AccountState.
fetch() now only extract credentials from the keychain, reports
the result to the AccountState which then decides if askFromUser()
should be called or not. The result is once more reported to the
AccounState.
This also replaces the HttpCredentials::queryPassword virtual
which now lets HttpCredentialsGui and HttpCredentialsText do it
the way that they prefer.
The AccountState is now the only class responsible for triggering credentials
fetching from the keychain or from the user.
With the ShibbolethRefresher out of the question it's possible
to remove the invalidateAndFetch virtual and manually call invalidateToken.
This also allows us to move that code from Account to AccountState.
In the end this also allows us to move the fetch() call from the
ConnectionValidator and use the same code path as for invalid credentials.
Previously, in case of an error while deleting a directory, we would not
remove the entries from the local db, despite most of the files would
be deleted.
Which means that if the files re-appear on the server with the same etag,
we would think the file were deleted from the client and propagate the change.
In 1.8.0 we had this bug that we would not see some directory in the server in
some cases. This would lead us to delete the file on the client. Normaly the
files are deleted from the local database and next sync would re-download the files.
But in the cases where there was an error deleting one of the file (for example
if it was locked) we would then propagate the delete to the server.
Fix this by always deleting from the database the files that we deleted.
Issue #3206
The original problem is that showing a popup not originated
from the main settings window while it's focused won't be
shown in front to the user.
This try not to highjack the user's attention of the user
by showing a notification when checking the connection for
valid credentials, and require the user to sign in through
the UI. There are still issues with showing that popup from
the tray icon, but the user will most likely be looking for
the popup in that case. The new sign in button directly in
the settings account works properly.
