After discussion and studying docs again we agreed that
the parameter is not neccessary here as it only affects
the process that opens the handle. And we do not want to
do async stuff.
I don't see a reason we should not allow this. We detect
a "failed stat reply" in other ways. Maybe this was a legacy
csync decision somewhow that is not valid anymore?
There were two issues:
* With the refactoring of how Folder and SyncEngine relate, the
ignore_hidden_files flag on the CSync context was reset after
each sync run and not updated from the configuration again.
* The folder watcher failed to enumerate hidden folders and thus
didn't watch for changes inside them. (linux only)
The creation doesn't need to be separated from the SyncEngine anymore.
This allows the SyncEngine to be created in fewer steps if we want to
use it in tests.
This moves most of the direct csync code from Folder into the SyncEngine.
The exclude file logic for the context has been wrapped using the
existing ExcludedFiles class as well.
Given that we control all call sites, the only way that this can fail is during
OOM. Also remove the code in csync itself to make sure that it's obvious that
any new error case wouldn't be handled by call sites.
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
* 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.
Since owncloud 2.1, csync_vio_local_stat was optimized because readdir
would already fetch most of the info. This works for the discovery,
but not later. And we used this function later for symliks and co.
So this fixes the .lnk on windows
Issue #4300
This conflicts with the KDE_INSTALL_PLUGINDIR and prevent the
dolphin plugin to be installed at the right location.
Since csync no longer have plugin, this can be removed
* Compute the content checksum (in addition to the optional
transmission checksum) during upload (.eml files only)
* Add hook to compute and compare the checksum in csync_update
* Add content checksum to database, remove transmission checksum
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
On unix we don't safe much (otherwise csync would have been
designed differently).
On windows however, the readdir already fetch all the info, so we
can as well use it.
We still have to query for the file id but we might optimize that later
