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
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 problem was if there was a false conflict: the file has been touched
both on the server and the client.
- etag has changed on the server
- mtime has changed on the server and the client and is the same
- and file size is the same on both the server and the client
This may also happen if the file is uploaded on the server, but the client
looses connection (or crashes) before it get notified of the etag.
In both tree, the instruction is EVAL, but we reduce it to a NONE because
we detected that the conflict is 'false'. Still, we need to update the db
with the new etag. (_should_update_db)
The problem was that we would set the flag on the wrong tree.
This was not a problem when the file was NEW on both side since we checked
for null etag and used the other one then.
In case two renames are done on the same file/folder very quickly we
lost the information that the second operation was also a rename. That
was because we tried to get the inode value from a stat on the file once
the first rename was finished. But at that point, the file was already
gone because of the second rename.
Now the original inode is kept and written to db in case the file can
not be stat'ed.
This fixes bug #1737
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
