Use qCInfo for anything that has general value for support and
development. Use qCWarning for any recoverable error and qCCritical
for anything that could result in data loss or would identify a serious
issue with the code.
Issue #5647
This gives more insight about the logs and allow setting fine-tuned
logging rules. The categories are set to only output Info by default
so this allows us to provide more concise logging while keeping the
ability to extract more information for a specific category when
developping or debugging customer issues.
Issue #5647
The sync engine rely on the 'M' in premission to ask for confirmation
(As requested in issue #5340)
But we only want to ask the premission for the 'root' of the mounting point and not
for every subfolders within it.
So we change the discovery phase in a way that it does not keep the 'M' for
children within the external storage.
Added two checkboxes in the Account Wizard in the advanced page to change the first options.
Also added a checkbox in the general settings to ask for confirmation for external storages.
Theme options allow to hide the checkboxes in the wizard.
As described in issue #5340
The "S" in the permission is only for the "Shared with me" files.
It is only used to show the shared status in the overlay icons.
But we also wish to show the shared status for files that are shared
"by" the users. We can find that out using the 'share-types' webdav
property. If set, then we are sharing the object.
We fake a 'S' in the permission as for our purpose, they mean the same.
Issue #4788
Issue #5224
Two problems:
- In the discovery phase, we need to check the selective sync entries of
the source path in case of renames.
- When the rename is done, we need to actually update the black list in the
database.
Reverts commit 622017adcf
Could be the cause of #5092 and the cost is higher than the benefit if this is the case.
A network request taking more than 30 seconds isn't something unlikely in this world
and shouldn't be a good reason to abort. We should try to untangle the threads
dependencies to properly fix this if possible instead.
Since the SyncEngine now quits and waits for the discovery thread,
the main thread can enter a deadlock where the discovery thread waits
for its directory result.
Add a 2 seconds timer to the discovery thread wait condition
to limit the deadlock time.
The ".sys.admin#recall#" is the recall file and should not be ignored
even if hidden.
The remote discovery do not need to detect hidden files because it
is already detected by csync in all cases. So this avoid code duplication
A 403 is a reply code sent from the file firewall to indicate that
this directory is forbidden to use for the user.
The patch handles it by setting the state to IGNORED.
This addresses #3490
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
The default constructor of the iterator points to NULL, which makes
it != end() but invalid to dereference.
Use an integer index instead to keep 0 as a valid default value that
can always correctly be checked against size().
Also make sure that no data is shared between threads by making the
csync_vio_file_stat_t copyable and passing it as const.
