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
That reads the credentials from the mirall config file if it was not
defined on the command line. Moreover, the connection is validated
before, which sets up the credentials properly.
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
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.
Volkan Gezer