The fix in commit 86d8079 made the detection of changes inside
a directory more robust.
As a result, changes are detected inside a directory, even if the
files that are changed were moved away on the other remote, the algorithm
won't let the directory be removed and the directory will be re-created
Found while investigating #2296
The problem is that we should not remove a directory locally if it contains
modified files.
But the modification time of the directory is not necessarily chaning (so
the instruction of the directory may still be NONE)
We have to move the child_modified test a bit down to be recursive
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
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.
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
