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
So we avoid lots of memory allocation.
We can work with char* directly since both the pattern and the file
name are in UTF-8 and there is no need to understand unicode for
such pattern.
(In fact, '?' would not match anyore non-ascii characters, but I
don't think that's a problem. I don't think anyone use '?' in its
exclude list. And the two allocations per call to csync_fnmatch are
really worth getting rid of)
Otherwise win32 api simply does not open reparse points at all,
such as junctions.
This will improve the user experience of #3813 as we now identify
the junctions as symlinks.... and ignore them properly.
Use an iterator variable declared outside of the loop condition
expression.
MinGW doesn't support C99 very easily and it's easier to keep
our C code C89 compliant.
This function only checks the full path and the basename and is thus
around 7x faster. It is very useful in a csync_update context where
we know that the leading dirs have already been checked for exclusion.
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
csync_vio_local_unix.c:109:7: warning: ignoring return value of function declared with
warn_unused_result attribute [-Wunused-result]
asprintf(&file_stat->original_name, "%s/%s", handle->path, dirent->d_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That allows better handling of remove requests that should not be done
because the directory is not empty on the remote side (as it contains
ignored files).
Before we only had c_utf8_to_locale, but now functionality is needed to
convert a path to UNC before converting it. That does c_utf8_path_to_locale
now, while c_utf8_string_to_locale only converts the plain string, ie.
to generate wide char strings for output.
This enables the calling function to free these accordingly. That is needed
because the makeLongWinPath for efficiency reasons does not always realloc
the original string.
