File delete by mistake when it was modified and his parent's directory was moved or renamed

I'm sorry for my poor english

Steps to reproduce
1.modify a file in a folder who is in a shared folder
2. rename or move the folder before all other clients have syncing the modification
3. when a remote client synchronise, it rename or move the folder with all the files
4. the remote client download the file modified in the new emplacement
5. the remote client propagate information on server that the old file in the old emplacement was deleted
6. all other client receive wrong information about file deletion to the new location
7. the file can be restored in the trashbin from the first remote client who has syncing the file

Expected behaviour
The file don't be deleted

Actual behaviour
The file is deleted

Client configuration
Client version:2.2.3
Client operating system:all windows platform i've tested (w7-x64, w8-x64, w10-x64)

Server configuration
Operating system:debian 8.6
Web server:apache 2.4.10
Database: mysql
PHP version: 5.6.24
ownCloud version (see ownCloud admin page): 9.1.0
Updated from an older ownCloud or fresh install: update from 9.0.1, but problem exist before upgrade
ownCloud log (data/owncloud.log):

I've the same problem on another server who was upgrade from 8
I've another server on version 8 who have problem.

Special configurations (external storage, external authentication, reverse proxy, server-side-encryption):

I mean that's the idea about syncing that all clients have the same version. What is your intended behavior? Each one must accept the changes? Or only if there is a large number of changes?

Even if you say that if someone moves a file out of the shared directory, everyone else should keep the file shared. What is about the user who moved this file out of the shared folder? What happens if someone makes changes, are these propagated to the person who moved the file to a different directory? This person might not be happy that this file appears again even though it was moved.

I don't move the folder who are shared, but one folder in the shared.
I test in a folder was not in a shared folder.
I'll have a folder named folderA who contains two folders folderB and folderC.
The folderB contain a files who are named fileA.txt

I'm connect on my web interface and i've a syncing client who have the same folders and files syncing.

I resume the syncing client to simulate deconnexion.

In the web interface , i editing fileA, and save it. Just after i move folderB in folderC.

When i use again the syncing client, it move folderB in folderC with the file fileA, and after it download again fileA (new version).
But during the next verification, it say to server that fileA in the older location was delete.
The server misunderstand and delete the file in the new location.
The syncing client delete the file in the new location.

The problem is more general that i think when i create that ticket. I've too with client version 2.2.2

Best regards

Thanks for this clarification. This is a serious problem. Can you share some more information about your owncloud setup (used apps, encryption app, external storage) that someone can reproduce the error.

I've no apps added, no encryption and storage is internal.
I can give an access to one server if necessary.

I tried to reproduce it (sorry my client is on Linux, version 2.2.3), steps:

  • create user1 and user2
  • share folder with them which contains folderA and folderB
  • place file1.txt in folderA
  • sync user2 with desktop client, then pause the sync process
  • login to webinterface with user1, modify file1.txt and then move from folderA to folderB
  • resume sync process for user2

Sync client:

  • deletes folderA/file1.txt
  • downloads folderB/file1.txt

I haven't tested it with a Win-client but the steps reproduce your situation @lfontaine35 ?

it's the folder who must to move, not only the file
when i move file, i'don't have the problem
folder A in folder B



you can too, just rename folder A


best regards

I see the same on Linux. Please open a bugreport on


ok, thanks for your help.