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.
Because that's what's going on. A job can 'complete an item' or 'finish'.
Note that several jobs could complete the same item: a new directory
will complete on the PropagateRemoteMkdir and the PropagateDirectory
jobs.
Previously, PropagateDirectory jobs didn't emit the completed() signal.
Now that they do, we need to make sure to not add extra lines to the
protocol widget for them.
To accomplish that, the jobCompleted() signal now also contains the job
that completed the item.
instead of pretending it suicceed and not recursing in it.
This fixes a bug in which a folder with a too long name would be properly
created, then removed on the server in the next sync.
(cherry picked from commit 4bbf7669091cde7ec726b1708d8c54427b68f016)
Conflicts:
csync/src/csync.h
csync/src/csync_exclude.h
csync/src/csync_update.c
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)
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
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.
To allow forwarding all OK states of sync jobs to the socket API
we need to make sure that the vector doesn't contain unneeded items.
This initially was intended to force updating the metadata for parent
folders, but since then the should_update_metadata flag check was
added both here and in PropagateDirectory::finalize where the metadata
is actually updated for parent folders. We can safely remove the inclusion
of all remote directory items.
The signal is emitted in this case if the instruction is NONE
but in the only ultimately connected slot to this signal,
SocketApi::slotSyncItemDiscovered, we return early according
to the same condition.
The emission of the same signal at the end of treewalkFile remains
and take care of the normal cases.
- Remove the copy constructor. The default constructor is fine. Having
a user defined copy constructor inhibit the move constructor.
- Pass QVariantMap arguments via const references
- Do not return a pointer to Capabilities from the account. It is a
value type and should not be used by pointer.
The proxyAuthenticationRequired() signal now goes to the
ProxyAuthHandler class. That class will try to read the proxy settings
from the keychain or ask the user about them.
We won't ask the user for credentials for explicitly configured proxies.
It also does not change how the credentials for explicitly configured
proxies are stored. (see #261)
