Wrong SV_MOVED generated when GetDelta is called while Move() is in offloaded queue

[Roman Yepishev]

14:35:09 <facundobatista> alecu, ok, the situation is this one
14:36:40 <facundobatista> alecu, you create a file B, it's created in the server; then you move it to C, but before C is really executed, client asks for a GetDelta
14:37:14 <facundobatista> alecu, in that GetDelta, the server informs that the node is called B
14:37:47 <facundobatista> alecu, so, client says "ha! here it's called C, in the server it's called B, somebody else renamed it, SV_MOVED!!
14:38:13 <alecu> facundobatista: oh, so that's a "synthetic" SV_MOVED, not a real one, right?
14:38:16 <facundobatista> alecu, this can happen also with changing parents also (it's also "moving")
14:38:23 <facundobatista> alecu, yeap
14:38:42 <facundobatista> alecu, *but*, wait, this case is already handled in the client!
14:39:57 <facundobatista> alecu, before generating the synthetic SV_MOVED, the client grabs his chin and thinks "hey, what if we're in the situation of an already moved file here that the server still doesn't know about?"
14:40:29 <facundobatista> alecu, so, it checks internally if there is a queued move from itself that still didn't get into the server
14:40:42 <facundobatista> alecu, sooooo, the bug is:
14:41:16 <facundobatista> alecu, the client's Move operation was offloaded to disk and it's only checking for the queued move in the in-memory operations

[Alejandro J. Cura (alecu)]

The SV_MOVED is wrongly generated on the client, because SD is not looking in the offload queue.