When recovering from a inalid move operation, we call
avoidReadFromDbOnNextSync. This will remove the fileid from the db so
we don't detect a move on the next sync. But we want the next sync to fetch
the file id again, and this can only happen if we don't read them
from the db and do the actual PROPFIND, this is done by avoidReadFromDbOnNextSync
However, if there is propagation in that source directory later, it
will overide the invalid etag with the real one and we will not uissue the PROPFIND
to fetch the fileid.
We must therefore also protect the future write to the DB when calling
avoidReadFromDbOnNextSync
Otherwise the buffer might fill up too quickly and get too large and consume
too much memory which could lead to crash in extreme cases
Should fix issue #1974
When using the "Limit automatically" limit, we wait for 25% of the time
it took to upload something.
However, if we go to sleep while uploading, the time it took to upload may take
days. And waiting for 25% of a day is too long.
So never wait for more than 10 seconds
This may be related to issue #1880
Before, we would only detect it if all the files were removed, and no
file where added or changed. This may not be enough because there might
be a welcome.txt file. Now, we check that none of the file stays the same,
and some files are removed.
Relates issue #1948
We can't call csync_set_userdata in owncloudcmd because it is
going to be overwritten later in the SyncEngine.
So we had an object of type SyncEngine* that we cast to CmdOptions*
and the trust flag was in the padding, so was some random data.
Therefore we must use global variables in that case in order to
know if we should ignore the certificate.
That macro is new in Qt5, define it as well when compiling with Qt4
so we can use it in mirall
Note: QNetworkCookieJar::deleteCookie was not existing in Qt4.
Headers need not to be added if they are not going to be installed
The list was incomplete anyway, and most of the _HEADERS variables
were even not used
Those class are maintaining the folder for the mirall configuration
They are not usefull in command line clients
Also the FolderWatcher is only used by the folder and not used by the
command line clients
We decided that we never want to rename a directory behind the
back of the user as the user may be using files in the directory
during the sync.
If moving is not allowed, we just erase the inode form the database so
the next sync will try to do an upload and delete and recover from there
using normal resolution.
This also add some code to update the inode back to the db when it is detected
as changed.
The mutex is not shared with any thread, so it is totaly useless.
Yes: there are possible races here. (with the account, but also with the
user and password)
In order to avoid the warning
warning: anonymous variadic macros were introduced in C99
Due to the use of variadic macro in the qDebug macro in Qt 5.3
C++11 requires a space between string literal and macro to avoid the
ambiguity with user defined litteral
While uploading a new folder, if the folder is renamed on the server
when still uploading, the result will be that the files that are already
uploaded will end up in the new filder name, but the file that were
not still are in the old folder.
After renaming, all the new uploads wil fail with an error on this sync
because the parent directory don't exist.
But they were uploaded with the old name in the next sync because
the renaming was not detected because the file id was not in the DB
Fix the problem by fetching the file id always when creating a new
directory, on the next sync, and saving it in the database ummediatly
https://github.com/owncloud/enterprise/issues/191
The current code only update the permissions in the DB when
the permission becomes non-empty.
Now we update the permission each time they change.
That way the code is the same for file id and permission so it is
simpler.
To distinguish no permission present to nothing is allowed.
That was the intention of the old code but it did not work as
the first if was always taken
Since remotePerm from csync is never NULL (as it is a buffer),
we consider that if it is empty, there was no permission set
(and therefore everything is allowed)
csync will put a space in the permission if any permission was set
If the result of a restored directory is SoftError, this prevent
to sync the rest of the directory
Therefore, we introduced a new status Restored, which means that
the job was a success, but is a restoration and therefore should be
seen as a warning
when the instruction is NONE, we may return from this function
before having registered the permission in the SyncEngine::_remotePerms
hash.
Move the code a bit up.
If we don't have the cookie in the keychain (e.g. the keychain is
unavailable) but there is still session cookie in the cookie jar,
showing the browser won't ask for authentication.
The legacy job might still need the neon session and the propagator.
We need to make sure the thread exits before.
This fixes crash when pausing a sync made with the legacy jobs
(for example when there is network limitation)
This should fix https://github.com/owncloud/enterprise/issues/200
Direcotries are removed at the end, and we don't want to update
parent directory etag before the delete is performed, or the next
sync may read from db and think the files are not removed.
Issue #1845
Olivier Goffart