Windows desktop app; re-uploads instead of moves

Desktop
1

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: 10.3.2.2

Storage backend (external storage): SMB attached drive

Client configuration

Client version: 2.6.0

Operating system:Windows 10

Logs

Annotation%202020-02-02%20153531

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

1 Like
2

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

2 Likes
3

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 folder.to 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.

4

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
5

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)

6

@joholm is definitely onto something here.

7

(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.

8

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

1 Like
9

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)

10

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
11

Hi eneubauer,

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

12
1 Like
13

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)

14

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
15

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
16

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?

17

Hey,

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.

18

Hi,

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.

19

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
20

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!