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
We fetch the id from the server, but don't save them in the database.
I Could have used INSTRUCTION_UPDATED for that, but then i would need to update the
reconcile algorithm to take in account the fact that UPDATED is possible there.
Instead, use should_update_etag which means the db is going to be written again
Remove reference to old instruction _UPDATED and _DELETED which does not make sens with
the new propagator
Improve the test to test this case, and that etags are properly writen to the DB
when there is a fake conflict
Since we removed the vio abstraction, we cannot use the file system anymore
as a remote. and because we unfortunately can't use a real server,
just disable that test.
