This currently is no-op code since the socket API isn't notified
that the tainted folder list changed, and the result is the same
since a sync will be triggered within the next 5 seconds and the
modified folder will be shown as SYNC at that point anyway.
Removing the dependency to the file watcher allows moving the
status estimation logic to libsync.
This will help moving the SyncEngine construction in the constructor
and allow moving functionalities from Folder to SyncEngine or its
delegated objects.
The policy that was said is that if a notification has no action, the
client can and should display a close-button. This patch does it.
In additon to that, the client needs a blacklist of closed notifcations
otherwise they would re-appear next time the server notifications are
fetched again.
Also, changed the cleanup of not-longer-used widgets to be more robust.
If a notification is not longer in the list that comes from the
server, the notification is removed.
That is mainly for the notifications that are created by the
announcement application
Since the quota is a per-folder value, this will make the displayed data
more useful when a single sync folder is configured.
Of course each subfolder could have a different quota again.
The date we receive from the server is an ISO8601 datetime that
includes the offset from UTC. Qt does correctly parse this
information and creates the appropriate QDateTime object.
Calling setTimeSpec(UTC) will force the timezone offset to 0 and
thereby change the referenced point in time to an incorrect one.
Soldiering on with a broken or incomplete response could lead to
incorrect sync behavior.
Since discovery uses LsCol jobs which already handle errors
correctly, this should not have a significant impact.
the size on the server might be different from the size on the client
with certain backend so it should be ignored.
(cherry picked from commit 9222db6df9b19a21e1bea5a238d745d96a6385e3)
In SQLite bindings are not cleared by sqlite3_reset() calls, so
skipping a sqlite3_bind call to create a NULL value doesn't work,
instead the previous value will be written.
To fix this, I clear all bindings in SqlQuery::reset and make sure
to explicitly bind NULL when desired in SqlQuery::bind.
To make sure there's no confusion about SqlQuery::reset and
sqlite3_reset, I rename our method to reset_and_clear_bindings().
(cherry picked from commit 7bd4f95b8c)
In SQLite bindings are not cleared by sqlite3_reset() calls, so
skipping a sqlite3_bind call to create a NULL value doesn't work,
instead the previous value will be written.
To fix this, I clear all bindings in SqlQuery::reset and make sure
to explicitly bind NULL when desired in SqlQuery::bind.
To make sure there's no confusion about SqlQuery::reset and
sqlite3_reset, I rename our method to reset_and_clear_bindings().
The isValid check should be used everywhere the capabilities
are used as the loading of the capabilities is happening
in parallel of the startup, so it is not guaranteed to be
available always.
As interaction is required, the notifications are displayed in a
separate widget above the server activity list.
Note that design and also where we display the notifications can
still be discussed and changed.
If the ownCloud server does not have the activity app enabled,
it returns 999 as status code. If all the configured accounts
do that, this code hides the entire tab with the server
activities.
This is supposed to fix#4533
Helps with small file sync #331
When I benchmarked this, it went up to 6 parallelism and
was about 1/3 faster than the previous fixed 3 parallelism.
Doing more than 6 is dangerous because QNAM limits to 6 TCP
connections and also the server might become a bottleneck.
Should also help for #4081
Previously one could accidentally call Folder::setSyncPaused() and miss
some expected side effects. Before, the correct call was to FolderMan::
slotSetFolderPaused(). Now the setter on Folder has the expected effect.
This will be useful if we ever want to store account-level gui state.
I built this originally because I thought a paused account would be
this kind of state.
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.
As discussed with Klaas, this seems to be a better compromise.
10MB * 3 prarralel jobs = 30MB in memory, and to retry in case of
disconnection. Which is still reasonable. And might make the upload
almost twice as fast on fast network where the amount of chunk is the
bottleneck (because of more server processing)
Relates to issue #4354
If the PROPFIND return an invalid code (like 200) then we would
not recieve the error signal and we would never sync again.
Found while investigating https://github.com/owncloud/enterprise/issues/1068
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
Users have complained that they don't see the notification when it is
shown and are not aware that their files aren't syncing.
Remove the non-interactive credentials fetch logic and add make sure
that the shibboleth popup will flash in the taskbar instead.
This will still not allow the popup to show in front in all cases,
but this is a compromise that we have to chose.
This reverts commit dcb687929f.
Issue https://github.com/owncloud/enterprise/issues/990
This is the fix for issue #4370
Step to reproduce the bug:
1) have lots of files in directory "dir1"
2) do mkdir dir2 && mv dir1/* dir2
3) DURING the sync (which takes time because of the many moves) do mkdir dir3 && mv dir2/* dir3/
4) observe that files are PUT in the next sync
The problem is that SyncJournalFileRecord::SyncJournalFileRecord will fail to
get the inode after the forst move because the files are already moved on the
filesystem. Normaly it should use the inode from the discovery phase in that
case but that is not working because it comes from the remote node in case of
moves, so the code in SyncEngine::treewalkFile would not set the inode.
Test in https://github.com/owncloud/smashbox/pull/143
Added a new "chunkSize" entry in the General group of the owncloud.cfg
which can be set to the size, in bytes, of the chunks.
This allow user with hude bandwidth to select more optimal chunk size
Issue #4354
QFontMetrics::boundingRect doesn't return the right size for this
font size for some reason, while it works well if we remove the
smaller point size adjustment for the progress font.
To avoid having to debug the font system in Qt just increase the
existing +2px adjustment to +5px so that it renders fine.
Server older than 8.1 cannot cope with invalid char in the filename
so we must not send them from the client. We were already checking
for new files, but not for renames or new directories.
https://github.com/owncloud/enterprise/issues/1009
The height adjustment done to place the button in the middle of the
non-error area was only done for rendering. Make sure that we do the
same adjustment when mapping click events as well.
Also replace some wrong occurences of aliasMargin*2 for margin.
Previously we would fail to start if the directory was not existing.
This was working for relative directory, but it should also work for
absolute ones
https://github.com/owncloud/enterprise/issues/970
