The 2.6 client will introduce an index that depends on a custom
function.
This causes insersion onto the metadata database to fail if the database
it opened with older version of the client. (Which will cause the client
to abort)
Delete this index in this version in order to allow downgrade.
In addition, allow to load folder with version '2', but still write
version '1' in the config file
Of course this commit need not to be in the 2.6 release
Conflicts:
src/csync/csync_reconcile.cpp
src/csync/csync_update.cpp
src/libsync/syncengine.cpp
src/libsync/syncengine.h
Note: csync changes from 5e442f588e
are not included and will be fixed separately
Also, if there is too-new configuration, backup the file, show a
warning message asking the user whether it's ok to discard the
configuration from the future.
See #6504
Now the db entries for placeholders will have the full placeholder
paths. That way older clients will, on remote discovery, delete the
placeholders and download the real files.
We otherwise normalize all path in the C form, so we must have
the Folder's path normalized the same. Or all comparizon will fail
(such as knowing if a file from the SocketAPI or the FilesystemWatcher
are part of the folder)
Issue #4424
If the SyncResult incorrectly believes that there are no conflicts, the
tray icon won't be correct and there will be no warning about unresolved
conflicts on the account.
Nevertheless, it's pretty awkward that the IssuesWidget is better
informed about pending conflicts than the Folder itself. This kind of
backwards data flow is very confusing.
Unfortunately the only alternative I see is to either keep track of
this information in two places (also in Folder), or create a common
data-holding class that can serve as a model instance for the issues
view as well as provide data directly to the Folder - which would
have been a much larger change.
This commit adds client-side support for delta-sync, this adds a new
3rdparty submodule `gh:ahmedammar/zsync`. This zsync tree is a modified
version of upstream, adding some needed support for the upload path and
other requirements.
If the server does not announce the required zsync capability then a
full upload/download is fallen back to. Delta synchronization can be
enabled/disabled using command line, config, or gui options.
On both upload and download paths, a check is made for the existance of
a zsync metadata file on the server for a given path. This is provided
by a dav property called `zsync`, found during discovery phase. If it
doesn't exist the code reverts back to a complete upload or download,
i.e. previous implementations. In the case of upload, a new zsync
metadata file will be uploaded as part of the chunked upload and future
synchronizations will be delta-sync capable.
Chunked uploads no longer use sequential file names for each chunk id,
instead, they are named as the byte offset into the remote file, this is
a minimally intrusive modification to allow fo delta-sync and legacy
code paths to run seamlessly. A new http header OC-Total-File-Length is
sent, which informs the server of the final expected size of the file
not just the total transmitted bytes as reported by OC-Total-Length.
The seeding and generation of the zsync metadata file is done in a
separate thread since this is a cpu intensive task, ensuring main thread
is not blocked.
This commit closesowncloud/client#179.
Make ExcludedFiles something that is instantiated outside of
the CSYNC context and then given to it as a hook.
ExcludedFiles still lives in csync_exclude and the internal
workings haven't been touched.
... even if the file is not changed.
We get an UPDATE_METADATA in that case, so make sure we let the
SyncFileStatusTracker know about it.
That means we need to filter out UPDATE_METADATA in the other listeners
of this signal.
Issue #6098
We mostly trust the file watchers meaning that we don't re-scan the
local tree if we have done that recently and no file watcher events
have arrived. If the file watchers invalidate a subtree, we rescan
only that subtree.
Since we're not entirely sure the file watchers are reliable, we still
do full local discoveries regularly (1h by default). There is a config
file setting as well as an environment variable to control the interval.
This makes it unnecessary for FolderMan to manage the list and removes
the need for some forwarders.
This is done in preparation for follow-up commits that want to add
diagnostics to FolderWatcher that shall be available from within Folder.
