Windows desktop app; re-uploads instead of moves

Expected behaviour

In Windows explorer I do any of the following.

  • Rename a folder
  • Rename a file
  • Move a file from one directory to another

All of these can be accomplished by a simple move operation.

Actual behaviour

Sometimes a “move” is used
Sometimes files are deleted on the server and re-uploaded.
I see no obvious pattern in how it chooses what method to use.

I though maybe it depended on file size, but even moving a large (500 MB file) into a sub-folder and later back resulted in a “move” down on the sever (OK) and later a totally unnecessary server “delete/re-upload” on returning to the original folder.

This is very inefficient and there is no obvious reason for it

Steps to reproduce

  1. Select a file in Windows Explorer
  2. Drag to a sub-folder, observe Sync log and wait until idle
  3. Select same file again and drag and drop back to original place, observe sync log
  4. Repeat or vary file or folder until delete/upload is used

Server configuration

Operating system:Ubuntu 18.04

Web server: Apache/2.4.29 (Ubuntu)

Database: mySQL Ver 15.1 Distrib 10.1.43-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

PHP version: 7.2.24

ownCloud version:

Storage backend (external storage): SMB attached drive

Client configuration

Client version: 2.6.0

Operating system:Windows 10



Log file when moving Test_file.txt to a sub folder and back…
Test_log.txt (17.7 KB)

1 Like

Thank you for reporting this issue. We are working on a solution.


Hi, thanks for the reply.

I’d like to add here, something I discovered a couple of days ago - which turns this issue from an “inconvenience” into a potential disaster,

Many who use Windows Explorer will probably be familiar with the small but real chance of making an unwanted “drag-and-drop”. You are working fast, clicking away with the mouse, go to grab a window’s edge (extremely thin in current Windows10), miss the edge and inadvertently grab a file or folder, and by the time you have noticed you’ve un-clicked and dropped the file or folder somewhere else.

Well this happened to me recently, I drag-and-dropped a folder into a neighboring folder.

Seeing the mistake I immediately checked on OwnCloud client’s activity. Ideally it would simply use a move operation to make the equivalent move on the server.

But no, this time it chose to create a new folder on the server and was frantically uploading files from that the “new” location.

I checked the folder itself and it contained almost 7 GB in just under 8000 files.

OwnCloud progress bar stretched hours into the future.

What to do? (It would be good to know what the official advice is!)

Faced with hours of unnecessary uploads, and the the potential challenge of getting the folder back to the correct place afterward I paused the sync operation and quit OwnCloud client.

In Windows Explorer it took just seconds to move the folder back to its original location.

Then the big question - if I restarted OnwCloud and resumed sync, would it figure out what had happened and leave well alone?

Thinking about it now I should have “Removed the folder sync connection” and made a fresh start. The initial sync would find most files in correct places and not have too much to do.

Unfortunately I didn’t think of that. I restarted OwnCloud client and trusted it to be “sensible”:

Before I knew it, the majority of the files in my original folder had been deleted.

OwnCloud appears to have taken the new folder on the server, with the few hundred files it had manage to upload, as the “definition” of that folder. So it reinstated that folder in the original location on my PC with just that small portion of the files. Almost 7 GB of files were just obliterated in a flash with no question or check.

Luckily for me I keep numerous backup copies and was able to re-instated the files again.
Unfortunately OwnCloud client then took several hours re-uploading them to the server.

So in short the miss-handling of “moves” can cause much more inconvenience that at first sight, and the erroneous assessment of actual events coupled with lack of alerts when deleting enormous quantities of files is a recipe for disaster.

Was this a move inside the “ownCloud” folder or outside of the “ownCloud” folder?
Have you tried the virtual file system for Windows 10 which comes with the 2.6 client? I would hope that virtual files can really solve those (by mistake issues). Another trick which prevents such issues is to share things from a function user without delete rights and use the function user for deletes … that way a mistake can’t happen but still heavy copying of files could occur.

1 Like

The move was inside the ownCloud folder.

No I haven’t tried the virtual file option. (Don’t want to make things more complicated than they are)