Sync client recreates renamed folders after concurrent rename+sync

[PVince81]

Steps to reproduce:

1. In the web UI create three folders "a", "b", and "c"
2. Upload many files in the three folders
3. Setup the sync client and let it download
4. In the web UI, rename "a" to "a renamed"
5. Wait for the sync client to start syncing
6. While the sync client syncs, rename "b" and "c" multiple times to different names
7. For even more fun, also rename the folder "a renamed" to yet another name
8. Check the local sync folder, web UI and also the trashbin. If everything looks fine, repeat from step 4) but try and be fast and rename like crazy.

Step 8) could probably be simulated through scripting.

Expected result

The three local folders and remote folders are the same and have the final name, the one from the last rename.

Actual result

If you are (un-)lucky, the sync client will recreate the old folder using the name it had before rename, and it will even upload some files in it.
In my first test case it also deleted a single file from those folders, which I found in the trashbin.

I'll try and reproduce this again and provide some logs.

CC @guruz

[PVince81]

Versions

ownCloud client version 1.6.3
OC Server version 1.7.2

Edit: wrong version, sorry

[PVince81]

Note: I used pictures in the folders, it might or might not help to delay the renaming operation.

Hmm, I managed to make files disappear twice now, with no traces in the trashbin.
Very weird. 😦
Will try and pinpoint the steps and logs.

[PVince81]

Tried again, steps:

1. Create three folders "a", "b" and "c"
2. Inside each folder I have pictures with names like "a__.jpg", "b__.jpg" and "c_*.jpg" so I can find out where they went after renaming the folders
3. Rename "c" to "c renamed"
4. Wait for the sync client to start
5. From here, rename "a" to "d", "b" to "e", "c renamed" to "f"
6. Continue renaming while it syncs, "g", "h", "i", etc
7. Once the sync stops, you might see "a", "b", "c renamed" locally
8. Once the sync starts again, continue the rolling rename (remember, you are trying to confuse it)
9. Once the sync stops, wait for the next sync and let it finish completely.
10. If everything looks normal, start over

If you're (un)lucky, one or two of the folders will be empty.

In my case I iterated multiple times and ended up with the folders "oops" (empty), "tt" (contains the a_*.jpg files) and "zz" (empty).

Here are the logs, starting from the first rename:
https://owncloud.vincentpetry.net/public.php?service=files&t=f8353f5dc91a17aaa49161edc94f6f44

[odaata]

Yep, I can confirm similar behavior in my sync client. Basically, if you uploade large files that aren't synced yet and change the name of a directory somewhere above those files, it causes sync errors and creates new directories on the server with the old name. It also tends to split out the files before and after the rename. To delete the aberrant files, you have to remove them via the website.

[odaata]

So, has there been any movement on this bug? I think we're going to have to stop using ownCloud if this isn't fixed, since it causes data loss :-(

[PVince81]

Not yet. There is the idea of introducing locks but it would be a big architectural change and comes with several unsolved issues: owncloud/core#11804

But here I'm still wondering why the sync client auto-recreates the folder after it has been renamed.
I haven't checked whether it's doing it explicitly or whether it's the server backend that auto-creates it.

@guruz do you have an idea ?

I'd expect that as soon as the target folder was renamed, further PUT statements would return 404 because the parent folder doesn't exist any more.

[odaata]

OK, so it's a core problem that isn't going away anytime soon, eh? Bummer. I guess it's back to Dropbox (which, by the way, handles this use case perfectly). I'll let our users know... Thanks for your help!

[moscicki]

A couple of questions/comments:

1. is this about a real data loss or about the messed up directory structure (file end up in a trashbin or in unexpected directories but are not lost)?
2. what is your use-case so that this is a real problem? we noticed that vast majority of users never run into these kind of troubles because they use this kind of cloud storage in a simpler way that we usually imagine
3. I think that locking is a particularly bad idea and will not solve this problem (and will introduce loads of other problems)
4. I also think that this problem may be solved within the client because it is capable of tracking local and remote directory moves. It just needs to be made smarter handling such cases. This is not easy but others seem to do it correctly (e.g. seafile). So it is certainly possible.

[odaata]

1. There is definitely data loss - in that nothing is in the trash bin and not every file is still there in the end.
2. Yes, I tried to argue that this is something we should avoid rather than throw out the whole system, but now that users have seen that data loss is possible, they've lost confidence in it and don't want to use it. In fact, people have been saying that renaming "any" file results in data loss, though I can't reproduce that, so I think it's a bit of hysteria on their part. I would have never run into this problem, because I wouldn't rename something as I was uploading it, but apparently this happens quite a bit with other folks. From what I understand they are constantly renaming folders :-(
3. Not sure what the solution is - maybe keeping track of the order of operations, so that the rename happens only after all files have been uploaded? I wish I knew the codebase and had time to help with this!
4. This definitely occurs primarily with the client and when renaming directories on the computer rather than through the webpage. Dropbox handles this correctly, with an immediate update of the new folder name on the website and client.

[moscicki]

OK, thanks for explanation. I will try to write a test-case reproducing this because as a user I cannot agree to data loss either. Maybe we can join forces on this @jnfrmarks ?

[jnfrmarks]

@moscicki

Yes we can!

[ogoffart]

This should be better now. We are trying hard not to have datalosses.
Is this still with 1.8