Windows desktop app; re-uploads instead of moves

(For Windows Owncloud Client users)

It’s really simple.

In Windows explorer, find a folder in a sync’d area and rename it.

Then open the desktop client and check the Activity log to see what happened.

Then rename the folder back to the original name and check the Activity log again.

Doe the client use “Move” or “Upload” and “Delete” in each case?

Thanks for any replies.

Two moves, like I would have expected. Do you have a different observation?
Newest version for me, with VFS enabled.

1 Like

Thanks. No I get upload(newname) and delete(oldname) for the second step.
We don’t use VFS.
Latest stable and pretty standard installation (as far as I know)

One easy way to reproduce issues is by setting up an ownCloud docker compose stack.

Than you could set up your client to connect to that docker container and try to reproduce the issue in there. That way you know that your issue can be reproduced in a vanilla installation. That would help developers looking into the issue.

1 Like

Hi eneubauer,

I have no idea what a “docker compose stack” is - but I guess I can look into it…(any hints?)

1 Like

Thanks for the link. I can see that Docker provides a kind of virtual machine. So if we install everything again inside a Docker container - what would be the difference from what we already have? I don’t see what we would gain.

(Also I don’t know how we’d make the virtual version accessible from the outside world - seems like a lot of complications)

Docker ships the whole application in a container including libraries built by ownCloud, so it should all work as expected and is therefore less likely to have configuration errors, that would contribute to your error.

Then you have reproduced the error in a controlled environment, so devs have a starting point to look into it further.

1 Like

I just realized that this is an issue for which a bug fix is in progress of development. Unfortunately I’m unable to double check progress as I don’t know the exact issue.

I did see that you described using ownCloud client 2.6.0 and there is 2.6.1 available. However it was released before you opened the topic, so I doubt a fix for this already included.

Once version 2.6.2 is released you can give it another go.

Anyway, it would be finished when it is finished.

1 Like

Thanks for the information.

Whilst talking about Docker…

Is there a particular Docker image which contains a fully configured Owncloud? the link you referred to only goes as far as installing an “empty” Docker and pulling in Ubuntu.

Also - how would such a Docker be made visible as a web server so as to be able to connect from a client?


i just have found the issue reported by @joholm to the ownCloud team:

where i had found the following:

and this problem is nothing that can be solved in the short term.

I think the only thing what can be done now is to have some patience and re-check the issue for a possible solution provided by the ownCloud team.


Yes that is the issue I wrote.

As I explained there, I am not expecting a solution in the short term. I was asking for help in understanding the log files. There are numerous messages about failure to get a token (or similar) on the server. So possibly it’s a server configuration issue.

As advised by eneubauer I installed docker and docker-compose and followed the instructions to setup the latest owncloud docker image on our server.

All went fine and we can connect to the new server from Windows owncloud client.

Finally I repeated the simple tests of renaming folders and files.

The results are pretty much the same as with our own Owncloud server - often upload & delete are used instead of a move.

There is some interesting reproducability when following fixed cycles of repeated renaming, but nothing to suggest the underlying cause.

1 Like

Another test - I installed the latest Windows client on another PC, connected to the same docker image mentioned in my last post and sync’d with the test folder.

a) Same results when moving or renaming folders and files. Most often an upload & delete is used instead of the expected move.

b) When one sync’d PC does the unwanted upload & delete the second PC does a corresponding download & delete.

This is not good - to say the least!


We’ve been waiting now over 7 months and so far no useful help or solution.

We really need to be able to sort out our photo collection without Owncloud continuously up & down-loading gigabytes of files every time we move or rename a folder.

If Owncloud can’t function properly we’ll need to move on to something which can.


it seems the ownCloud people (at least one developer seems to have tried to reproduce it) are not really able to reproduce the problem in the linked issue below so i think there is not much hope to get a fix anytime soon :frowning_face:

Yes tried on a different platform with a different version. Not very helpful.
I have it repruducable on a simple Docker setup.
I think it’s weird that no one is interested in such a basic failing.


maybe it hasn’t much priority:

There are edge cases where the client does not get reliable information. Quite some effort has already been done to detect changes (e.g. checksum comparison), but the remaining cases are really hard to solve. Ensuring the integrity of the data is the higher goal than saving some GB.


That comment you referred to is absolute nonsense. These are not special “edge cases”. They are completely normal everyday situations. They could not possibly be any simpler.

Also, as I mentioned in another post, I use a Sync program for backup which handles the same moves & renames without the slightest difficulty when I run it weeks or months after the moves & renames took place.


David Bloomfield

Oh, sorry i haven’t followed all posts here and in the github issue as i’m not that familiar with all these information and technical details :frowning_face:

If this is just a standard operation / usage without any special configuration or edge cases maybe there is a misunderstanding by the ownCloud people then? I think it could make sense to explicitly state that in if not already done.

1 Like